Re: The future of HTTP

Message-ID: <3998006B.2201725B@canada.sun.com>
Date: Mon, 14 Aug 2000 10:21:31 -0400
From: Mark Baker <mark.baker@canada.sun.com>
To: xml-dist-app@w3.org
CC: http-futures@bluescreen.org
Subject: The future of HTTP

Hi all,

At the last IETF in Pittsburgh, a group of us got together and held a
"pre-BOF", after our request for an Apps area BOF was denied due to lack
of bandwidth.  At the end of this message is the description of the
pre-BOF that we posted.

All but one person who attended was an active WAPforum participant,
reflecting the need that the wireless community feels for some more work
to be done on HTTP, but at the same time identifying the need for
participation from other communities.

We've just set up a mailing list, http-futures@bluescreen.org

To subscribe, send mail to majordomo@bluescreen.org with "subscribe
http-futures" in the BODY

Archives are at http://www.avogadro.com/ietf/http-futures

==snip==

HTTP futures discussion/pre-BOF !!!!!!!!!!!!!!!!!!

This discussion will focus on issues related to HTTP at the edge of the
network. In particular, the Internet at large, and HTTP in particular
are
being stretched in new or at least more intense ways by the advent of
myriad
devices or appliances, and by the related shift in Internet connectivity
from wired connections to a higher number of wireless links (personal,
local
and wide-area).

This brings renewed and perhaps urgent interest to enhance HTTP.

This discussion will draw upon lessons learned from the HTTP working
group
as well as from the past activites on HTTP-NG.

We plan to address:
   1. Creation of a list of requirements.
   2. Creation of a list of issues which different communities
      have with respect to HTTP1.1.
   3. Discussion of whether HTTP1.1 is:
        a. Good enough as is, so leave it as is.
        b. Almost good enough, with a few fixes, so reopen HTTP
   1.1 to address the list of current shortcomings.
        c. Launch a new effort for a major revision/redesign of
   HTTP. In this case, there are several options:
- Reviving HTTP-NG and pursue the standardization of something heavily
based
on it.
- Basing this new protocol on something else (BLOCKS comes to mind).
[snip]

MB



----------------------------------------------------------------------------
----

Received on Tuesday, 5 September 2000 13:19:24 UTC