- From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
- Date: Tue, 18 Feb 1997 19:23:29 +0100 (MET)
- To: touch@isi.edu
- Cc: bertold@tohotom.vein.hu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> > > By the way, section 3.2.2 gives a the only clear definition of > > > http_URL, which indicates that > > > don't have the document handy, but if, as you say, the spec says > > two different things in two different places, it is just arbitrary > > to pick one definition as the correct one and the other as wrong. > > I did not. The question is twofold. > > HTTP can be implemented over whatever, as you observe. > > The spec is very clear on the meaning of http://, however. It > is TCP specific. Ok, now I get your point: here, and in the rest of your message, you make a very careful distinction between HTTP and http:// and I clearly failed in that. My personal impression is that in RFC2068 the word TCP is generally used to mean the underlying transport protocol, and in 3 sections (1.4, 8.2, 10.4) it is explicit that TCP is not the only possible transport, whereas it is never said that there cannot be other transport. The strict use of the word "TCP" in the definition of http:// might just have slipped in because of brevity, more than understandable in such a long document. Of course, the last word goes to the authors. > > Ok, current implementations use TCP over IP as the only transport, > > but I fail to see where the protocol is so tightly related to TCP/IP > > that it would be hard or impossible to make it work with another > > reliable protocol. > > It is tightly tied to a connection-oriented reliable transport > protocol. Sure, it CAN work with others; the question is whether > it's http: or not. I claim not. 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. Cheers 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:09:52 UTC