- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Mon, 27 Nov 1995 11:31:24 -0800
- To: West Suhanic <wsuhanic@acs.ryerson.ca>
- Cc: HTTP working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
> I think the central issue here is where the concept of media
> is handled. If the HTTP server is considered as a media server
> then it must have the facilities to deal with media.
>
> We've had this discussion at least once before. I firmly believe
> that HTTP should NOT be used for real-time continuous media. The
> URL mechanism allows us to include multiple transport protocols
> (e.g., HTTP, FTP, Gopher) in the web, and if we want to include
> real-time continuous, then we should use a protocol optimized for
> that. We should not try to turn HTTP into a kitchen-sink protocol,
> making it into a second-rate media protocol while also making it
> harder to implement.
>
> As a purely practical matter, this working group is chartered to
> work on IETF standards, which normally require "rough consensus
> and working code" to progress. We would be in relatively uncharted
> territory when it comes to real-time continuous media, which is
> still the subject of active research and debate. It would be
> quite premature to try to standardize this kind of thing, especially
> in the context of the most heavily-used protocol protocol in today's
> Internet.
I'll second this, and point out that the Upgrade header field in the
draft of HTTP/1.1 is designed to allow changes in application protocol
when the server wants to send a resource with these characteristics.
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/
Received on Monday, 27 November 1995 12:27:40 UTC