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: Bob Wyman <bobwyman@medio.com>
Date: Thu, 24 Aug 95 07:48:03 -0800
Message-Id: <199508241456.HAA26236@dns.medio.com>
To: "dmk@allegra.att.com" <dmk@allegra.att.com>, "birk@bodega.stanford.edu" <birk@bodega.stanford.edu>
Cc: "http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
-- [ From: Bob Wyman * EMC.Ver #2.5.02 ] --

Dave Kristol wrote: 
> IMO, this kind of method is outside HTTP.  I think it is best handled by
> (conceptually, at least) an outboard application,

I agree with this position at this time. 

I suggest that while Yitzhak Birk may have established a requirement for a
connection which provides the semantics he defines as being needed by "PLAY"
, what he hasn't done is establish the requirement that HTTP be the protocol
which provides the required semantics. Yitzhak's only attempt at
rationalizing that HTTP should be the mechanism for supporting PLAY is his
FAQ item in which he argues between HTTP and HTML. There are other
alternatives... TCP/IP supports many ports -- we don't have to pump
*everything* through port 80...

I suspect that the needs of those developers who require PLAY semantics
would probably be much better served if they were to consolidate into a new
effort to define a protocol which would be a sister protocol to HTTP --
designed to work well with clients which support HTTP. 

Play is not the only protocol type which is not well served by HTTP today.
For instance, I think you'll find that the Z39.50 folk and their ISO cousins
would argue that HTTP is inferior to what they are building when it comes to
handling the complex queries, record/field structured data values, etc. that
are typical of the applications they support. There is also quite a
community of game developers, virtual reality folk, system management types,
users of Telnet, etc. who would be giving up much if they were to try to
squeeze what they have into the confines of HTTP extensions.

The growing popularity of HTTP is certainly compelling, however, just
because it does what it does doesn't mean it should be made to do everything
else. It would be more reasonable to define a family of protocols that
interwork well within the context of a single, reasonably easy to construct,
multi-protocol client. 

		bob wyman
Received on Thursday, 24 August 1995 07:59:18 UTC

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