HTTP-NG Working Group?

The HTTP-NG BOF in Chicago was very helpfull to me both in
  understanding what has been done in the W3C Activity and in
  clarifying my thinking about how it should proceed within the IETF.

  My view of the essential elements of what HTTP-NG has done so far is
  that they have described:

  1) A framework that more precisely specifies application message
     semantics (the object-oriented NG interfaces).

  2) A more compact binary encoding for Web application messages.

  3) An application message boundary mechanism (the webmux fragments).

  4) An application association mechanism that supports multiple
     interleaved associations over a single transport layer connection
     (webmux sessions), including:

     4a) the association setup uses a very simple endpoint definition
         is be easily inspected by firewalls.

  5) A mechanism for describing a service stack below the application
     to provide additional services (compression, security).

  Despite the fact that many other proposed protocols have been
  choosing HTTP as a 'transport', I was suprised to hear that the
  HTTP-NG effort was being considered within the Transport Area rather
  than Application.  The main arguments that I heard in Chicago in
  favor of this were: that other protocols were doing it anyway (people
  are making a poor choice for the wrong reasons, so we should make a
  poor choice that will validate it?); and that webmux credits would
  have dangerous potential interactions with TCP flow control that
  needed transport expertise to understand (very good reason!).

  Having spent some time thinking about the list above, I have come to
  believe that some of the reasons why so many recent applications
  have been choosing HTTP as a substrate (it isn't a transport no
  matter how many times you call it one) is that it provides (3), (4),
  (4a), and (5) from that list.  These things are important
  requirements of a very large subset of all application layer
  protocols, and TCP does not provide them.

  I don't believe that a case can be made for putting work on (1) or
  (2) into the Transport Area, and I'm not even convinced that an
  object-oriented (or other) interface definition framework is a good
  direction for HTTP to go.  A binary encoding for HTTP/1.1 would be
  easy to do without the new paradigm, and would be a very interesting
  experiment.

  I do believe that 3 through 5 are desperately needed, and while my
  computer science professors would all have called those Session
  Layer, I'm willing to call them Transport if it means we can get
  them done once and well so that other applications can use them.
  With that in mind, I humbly offer my suggestion for a Working Group
  name: Enhanced Application Transport Services (eats).



-- 
Scott Lawrence           Consulting Engineer      <lawrence@agranat.com>
Agranat Systems, Inc.  Embedded Web Technology   http://www.agranat.com/

Received on Monday, 31 August 1998 18:25:18 UTC