Re: HTTP and Media Serving

> 	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    (
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056

Received on Monday, 27 November 1995 12:27:40 UTC