I dont beleive that a new scheme is appropriate nor a new TCP port.
I always thought that the scheme in the URL indicated which protocol
you are actually speaking on the wire. IPP *is* speaking HTTP.
It just has a different "service" than HTML, GIF, etc content
or GET/HEAD semantics.
How about if different services layered on HTTP are differentiated
at a within the HTTP layer. Looking at IPP/SWAP/ or DAV from the
TCP layer should make it appear to be HTTP.
When examining the message at the HTTP layer, it should appear
to be IPP/SWAP/DAV service.
In an analogy, lets look at HTTP as being TCP and TCP being where IP is.
(wait.. just give me a sec, I know this sounds wierd)
So, TCP differentiates itself from another IP protocol such as
UDP by using a different protocol number, right ?
When a new service/protocol is built on top of TCP, do
we expect the IP layer to understand it, or do we expect the TCP
layer to understand differentiation? I beleive it is
TCP.
So, you wouldnt ask a new service built on top of TCP
to allocate a new IP protocol number, would you ?
To make IPP, which is a layer on top of HTTP to expose
its differentiation at the TCP layer breaks the abstraction
layer. TCP is, in a sense, delegating the differentiation to the
HTTP layer, just like IP delegates to TCP to inspect port #s.
Another analogy is RPC. If a firewall wants to filter all
protocols on TCP ports, and it chooses to allow RPC, it must
be all or nothing. To selectively filter RPC it must have
an RPC proxy in the firewall.
This is the scenario I beleive is common for HTTP. If you
want to selectively allow certain HTTP messages of certain
URL types, methods, or content-types, you must employ a proxy
or device that can parse the HTTP layer.
> Keith
>