- From: Bob Wyman <bobwyman@medio.com>
- Date: Thu, 24 Aug 95 07:48:03 -0800
- 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