> Of course, anyone with an HTTP server on port XXX will be unreachable
> from behind such a firewall, and the filter won't block access to IPP
> servers on other ports. But that's an inherent limitation of
> firewalls -
> they can't really filter out all unwanted traffic, they can
> only filter
> out most of it.
>Its only an inherent limitation of firewalls/proxies if you
limit them to filtering based on TCP port.
Todays proxies and firewalls can do so much more if we just
let them.
IPP is a service, protocol, or whatever we call it that
"runs on top of " HTTP as a transport, substrate,layer or
whatever we call that.
Instead of setting up IPP to be filtered at the HTTP level,
we're asking it to be filtered at the TCP level, which is
two levels down.
Its like we're creating a new instance of HTTP on port XXX
which is underneath IPP called HTTPI.. We're claiming that
its a different HTTP than the HTTP that runs on port 80.
I'll mention again my RPC analogy. New RPC protocols
allow themselves to be filtered by using the semantics
(program no) of RPC. An intelligent RPC proxy or firewall
knows to recognize the different RPC protocols (NFS,NIS)
by looking at the RPC information such as program no.
To move this analogy into what we're saying, its like
we're saying that for NXS (a new RPC based file share protocol),
you run a new portmapper on a port other than 111, lets say
on port YYY. Now firewalls filter based on this port instead
of the perfectly reasonable program no.
(I think we're going to create a mess that will make
firewall/proxies lives harder instead of easier)
Basic HTTP provides
GET a uri
PUT a uri
(and others)
A proxy can filter different actions effectively without
ever needing to look beyond the HTTP layer by looking
at the method.
Why cant
PRINT a uri
fit right into this simple model with a PRINT method?
> As long as IPP is run on a separate port, I'm pretty ambivalent
> about PRINT vs. POST.
>> Keith
>