> The whole discussion as raised
> in Keith's feedback has to do with firewalls. Also, we are not discussing
> how easy or not it is to change the specs, but what the consequences are
> for implementors.
>
> My understanding is that Keith is trying to dictate that IPP CANNOT USE
> "http" - full stop. Considering that he has been the project advisor, I am
> very disappopinted to see that kind of proposal at this stage in the
> project.
I'm not sure that I interpreted Keiths comment that way - I believe
that the concern is (and it has been raised by others before this) that
a firewall admin has to look too far into the request to determine that
it is IPP. It is easy to come up with scenarios in which the admin
would want IPP to be able to penetrate where a POST would not (for
example, I install an IPP printer I trust _inside_ my firewall and then
set the firewall to allow PRINT requests to it from outside, perhaps
only from certain business partners).
I think that continuing to use http: and by default port 80 is fine, but
using a PRINT method gives the admins what they need; they can now
allow http PRINT to penetrate (or not) based on the method and the
destination server. The IPP spec would only need to specify that the
PRINT method is equivalent to POST for the purposes of all http usage
rules (cachability, etc - and in any event there are explicit headers
available in http [Vary, Connection, Cache-Control] to control these
things now anyway).
This is trivial change for any server that wants to be used for IPP.
The current state of proxies and firewalls on the real net is so widely
variable that I think any scheme we can come up with will have problems
with some anyway, and those technologies are evolving so rapidly that
there is ample opportunity for IPP to create an incentive to support
this kind of filtering.