- From: Albert Lunde <Albert-Lunde@nwu.edu>
- Date: Tue, 18 Feb 1997 13:52:03 -0600 (CST)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> For the "connection oriented" part, RFC2068 already makes it clear that
> a connection-oriented protocol is not necessary. For "reliable
> transport", that is probably a strict requirement for the headers only.
> Future extension of HTTP might well have to deal with data (e.g. audio,
> video streams) where reliability is not such an issue, and QoS might be
> negotiated (e.g. "I need that gaps in the received video are not longer
> than 5 frames"). Then, the body would not even need a reliable
> transport.
I think you-all are stretching things here. My reading of the current
state of things is that HTTP was designed to work on top of
a protocol reasonably similar to TCP, should the need arise.
A moderate degree of transport-independence is good design.``
I don't think it was intended to run on top of all transports,
and I don't think it should try to be the universal protocol
for all proposes. It seems quite reasonable to define a new URL
scheme for audio or video streams rather than overload http:
--
Albert Lunde Albert-Lunde@nwu.edu
Received on Tuesday, 18 February 1997 14:10:42 UTC