> -----Original Message-----
> From: Randy Turner [mailto:rturner at sharplabs.com]
> Sent: Tuesday, June 09, 1998 8:13 PM
> To: Paul Moore; 'Tom Hastings'
> Cc: 'Carl Kugler'; ipp at pwg.org> Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests
>> For reference purposes, can someone restate the problem (actually the
> scenario) with proxies that we are trying to address. I think some
> solutions that have recently hit the list are bordering on
> "throwing the
> baby out with the bath water". Any concrete scenario examples
> would be much
> appreciated, as I am still on the learning curve with HTTP
> proxy behavior.
>
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.