W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Proposal: a PLAY or STREAM method for http/1.1

From: Dave Kristol <dmk@allegra.att.com>
Date: Thu, 24 Aug 95 17:06:12 EDT
Message-Id: <199508242114.AA139738863@hplb.hpl.hp.com>
To: birk@bodega.stanford.edu
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Yitzhak Birk <birk@bodega.stanford.edu> wrote:
  > [...]
  > In summary, I argue that the PLAY semantics for streaming (as opposed
  > to truly interactive conferencing) do fall well within the natural
  > scope of HTTP, even for its current mainstream use, and believe that
  > their inclusion in HTTP would facilitate substantial and meaningful
  > performance improvements. In the absence of PLAY, I suspect that people 
  > will simply continue using GET rather than develop a new protocol for 
  > a subset of "HTTP-like" requests, and overcoming the resulting 
  > performance problems will be more difficult. 

I don't believe you can negotiate all the flow parameters in advance,
because the state of the network changes, and the changes affect the
streaming.  Thus it's likely there will be two-way communication
between client and server to adjust the data rate.  HTTP is ill-suited
for such communication.

People here at Bell Labs have done some work on real-time delivery over
the Internet.  (See <http://www.research.att.com/~hpk/nemesis.html>.)
They use a separate connection in an outboard application, which was
the basis for my earlier description.

I see that superficially the PLAY method fits into the HTTP paradigm,
but I think the details make the fit a poor one.  Adding a bunch of new
headers, and possibly client-directed flow control, means you're a good
way toward a very different protocol.  So make it a different protocol!

Dave Kristol
Received on Thursday, 24 August 1995 14:16:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC