W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: How to add new "protocols" ?

From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Date: Tue, 18 Feb 1997 19:23:29 +0100 (MET)
Message-Id: <199702181823.TAA07213@labinfo.iet.unipi.it>
To: touch@isi.edu
Cc: bertold@tohotom.vein.hu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2426
> > > 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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC