Re: How to add new "protocols" ?

> > > From 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


Joe Touch -
ISI / Project Leader, ATOMIC-2, LSAM
USC / Research Assistant Prof.      

Received on Tuesday, 18 February 1997 10:59:27 UTC