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

Re: How to add new "protocols" ?

From: <touch@isi.edu>
Date: Tue, 18 Feb 97 10:37:48 PST
Message-Id: <9702181837.AA01398@oak.isi.edu>
To: luigi@labinfo.iet.unipi.it, touch@isi.edu
Cc: bertold@tohotom.vein.hu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, www-talk@www10.www3.org
> > > From bertold@tohotom.vein.hu Sat Feb 15 09:02:38 1997
> > > 
> > > This is interesting to me. Look at this (excerpt from HTTP/1.1 spec):
> > >    "HTTP communication usually takes place over TCP/IP connections. The
...
> > Joe said:
> > 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, 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. 

> host and port are just identifiers, to the point that, even in
> current implementations, they are quite often remapped to other
> hosts and/or port numbers in a totally transparent way.

Huh? Since when does port 80 mean anything but? Proxies can
be used to fake you out, but that doesn't change what the
client thinks its doing.

> As a result of this discussion (for which I thank all who replied
> to my original posting giving useful suggestions), I am completely
> convinced that there should _not_ be a specification of the network
> transport protocol in the URL, since the same exact data might (and
> certainly will in the future) be available over different transports,
> and it would be a serious issue to embed the transport in the URL.

And how do you propose figuring this out? Checking all possible
protocols? In what order?

These are a few things a protocol might specify. HTTP 1.1 doesn't.

> To me, the use of TCP is as good as any other protocol, what I
> would be worried about is that the assumption of TCP/IP then creates
> TCP-specific details which would be hard to reproduce in different
> protocols (e.g. the use of IPv4 addresses as identifiers, etc.).

You're already stuck with most of that, as per 3.2.2, unless it's
revised.

Joe

----------------------------------------------------------------------
Joe Touch - touch@isi.edu		    http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM       http://www.isi.edu/atomic2/
USC / Research Assistant Prof.                http://www.isi.edu/lsam/
Received on Tuesday, 18 February 1997 10:59:27 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:28 EDT