When a proxy is deployed as part of a gateway, firewall or other
security system, one of its responsibilities is to filter and allow
or reject certain transactions across a network or organizational boundary
in either direction.
The issue is that the proxy should be able to understand enough information
to decide wether to allow or reject that request's passage. When given
an IPP URL such as http://server/printer/queue, it has no way of
differentiating
this from a typical web browser's form submission. Since form submission
and print job submission and or printer control are different in terms
of the anticipated functionality that the firewall admin allowed
(by allowing POST http requests ), the admin should be able
to allow one and not the other.
The real world case is a firewall/proxy administrator who
sets a policy which allows POST because his intent is to allow
"simple web access", which form submission is a part of. Lets
say in this case that he is willing to allow simple web access,
but he is not interested in allowing IPP functionality, ie
print job submission and printer control.
At the time IPP went to last call, the specification was to use
POST with an http URL. This did not meet the goal of allowing
a proxy server administrator to recognize the request as an IPP
request instead of a form submission.
Keith has come back with the request to somehow make IPP requests
identifiable as different from simple http POST form submissions.
Numerous suggestions have been made, as referenced by carl-uno's
recent posts of the table.