Chair | Area | Mailing List | Description | Scope | Goals & Milestones | Working Drafts | Background
The <ietf-http-ng@w3.org> mailing list and archives are available for discussions of the HTTP-NG Project. You MUST be subscribed in order to post to this mailing list, see the Mailing list administrativia for details.
The work undertaken by the HTTP-NG Working Group (NG) is to factor HTTP into three layers, to obtain the well-known benefits of modularity in general and, in particular, better structure the large and growing family of uses of HTTP and HTTP-like protocols:
We expect this three-layer structure will 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.
@@@I don't think we have to say much more about what NG is but rather what it isn't which is why I have focused on the scope section@@@
@@@Should we also make a requirement of a testbed? IPV6 deployment has this, I think it is a good idea@@@
The NG framework proposed is likely to be useful in many applications not directly related to the Web. Although it is tempting to provide generic solutions, the primary focus of the HTTP-NG Working Group is to provide a new protocol infrastructure for the Web. This means that any conflicts of interest should be solved in the favor of the Web.
Especially, ongoing Web characterization work, for example as provided by the W3C, see interactions with external Groups, should be taken into consideration by the Group.
While especially the WebMux layer interacts closely with TCP, it should not provide a TCP replacement. Rather, WebMux defines a set of services often needed by Web applications. These services must be implemented in such a way that interact seamlessly with TCP services and do not hinder the independent evolution of TCP.
While experimenting with transports other than TCP, for example UDP and multicast, is of direct interest to the HTTP-NG Working Group it is not considered within scope of the Group to ensure that these transports are directly supported in the NG architecture.
The NG architecture is intended to help service designers to use the Web and HTTP in a more seamless fashion than what HTTP/1.x allows for.
@@@Should probably say more about interactions with DCOM, CORBA, and RMI@@@
Although a machine/human readable representation of the interfaces is needed, it is not within the scope of this Group to produce a new interface definition language , possibly generated from other IDL's
Both text based and binary protocols have known advantages and disadvantages in large scale deployed systems. Especially the characteristics of text based wire encodings are well-known from the experience of HTTP/1.x where the performance implications of a text based protocol are not to be neglected.
The wire encoding provided by the Working Group may be either text based or binary but in the latter case, the NG architecture should at least support a text based wire encoding although the Group is not required to design a text based wire encoding.
@@@TBD@@@
A requirement for providing a scalable next generation HTTP protocol is to provide well-defined semantics for caches and proxies within the NG framework. The Working Group must define and demonstrate the feasibility of proxies and caches as an integral part of the NG solution.
Although proxy discovery mechanisms is a crucial part of the Web infrastructure, it is not considered within scope of this Group to provide a proxy discovery mechanism. However, a discovery mechanism should be considered as a likely application of the NG framework.
It is also not in scope to provide a scalable replication and mirroring infrastructure although again, it should be considered as a likely application of the NG framework.
A transition plan must be defined by the Working Group. This task is expected to include but not limited to the following:
1. Define the processes by which the Web can be transitioned from HTTP/1.x to HTTP-NG with the expectations that any interim period will be of no less than 50 years (see RFC 2277). As part of this effort, the Group will produce a document explaining to the Web community as well as to the Internet Community in general what mechanisms will be employed in the transition, how the transition will work, the assumptions about infrastructure deployment inherent in the operation of these mechanisms, and the types of functionality that applications developers will be able to assume as the protocol mix changes over time.
2. Define and specify the mandatory and optional mechanisms that are to be implemented in clients, servers, and proxies, and other components of the Web in order for the transition to be carried out. Especially, the interactions with HTTP/1.x proxies must be defined.
In order to ensure deployable solutions that allows the Web to evolve, the Group must coordinate with existing Web characterization projects like the characterization effort undertaken by W3C. Furthermore, the Group must demonstrate the feasibility of the solution based on realistic user scenarios representing operations performed on the Web.
@@@ Other Groups that may be of interest?@@@
Here is the list of drafts that were presented and discussed at the HTTP-NG BOF: