- From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
- Date: Tue, 18 Feb 1997 21:19:52 +0100 (MET)
- To: Albert-Lunde@nwu.edu
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> > 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. You are certainly right, I started writing the above paragraph with something like "Going to the extreme, " then I edited it out. ... > 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: You see, the problem is that protocols (either at user or network level) tend to become "de facto" standards when they are successful, and then you are stuck with them. So it was for TCP (and we are discussing now whether http is over TCP only rather than Decnet only), so it might be for http. And, just as a practical issue, I don't think you can instruct your favourite browser to digest and pass to a proxy a request for, say, xytp://host/file. Finally, why should one go through the effort of reinventing the various issues (content negotiation, caching, etc.) which HTTP already deals with in what I believe a very flexible and satisfactory way ? Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________
Received on Tuesday, 18 February 1997 14:11:10 UTC