Re: Proposal: a PLAY or STREAM method for http/1.1

> 
> - Whether we like it or not, the different beasts do and will share the 
> network. There (e.g., ATM forum), the issue of coexistance of traffic of
> different types is being addressed. Among other features, ATM supports 
> bandwidth reservation. 
> 
Reality insert:
The different beasts will share a *network*, but not necessarily a network
*connection*.

I believe that if you want to PLAY, say, an MPEG, you would want a connection 
that:

- has a separate IPv6 flow ID, so that the applications can negotiate with
  the routers about it (most probably either the workstation or the server is
  NOT directly on the same ATM netowrk, so an extra ATM channel won't be
  end-to-end. Don't use ATM as an argument without a clear picture of how ATM
  and IP will coexist!)
- is carried over UDP, not TCP, so that data delayed for too long will be
  dropped, instead of delaying the rest
- features recipient pushback, so that when the loss rate on your 400 Kbit/s
  CD-ROM quality playback goes above 90%, you switch to 16 Kbits/sec GSM
  encoding, giving tinny sound rather than garbled sound
- allows recipient abort, so that when you discover that "A nightmare on
  Elm street" isn't about tree conservation, you don't have to transfer
  the rest of the movie.

I don't think any of these things can be optimally achieved using HTTP/1.1;
I suggest you concentrate on defining a play: URL instead.

Oh, and BTW: playback over the network is being addressed by the AVT WG,
and IP over ATM is being addressed in the IPATM group. Resource reservation
is done in the RSVP group.
I will certainly ask all these groups' chairs to comment once you come
back with a Play: URL spec; it might be a Good Thing to read their stuff
first. (At the moment, URL specifications must be defined in standards-track 
documents, which must pass through the Apps area directors)

    harald A

Received on Friday, 25 August 1995 02:52:41 UTC