Thanks for the synopsis. It appears that the administrative capability to
filter IPP traffic via proxies is a feature that Keith thinks should be
provided by IPP. If this is the only key issue holding up our spec, then I
would like to suggest that we look into a new method (such as PRINT), and
avoid (for now) the issue of new schemes and/or port numbers for IPP. It's
the "short path" in my opinion to getting us going again.
As far as proxy-rewriting of request URIs, I'm still not clear this is an
issue; the "abs-path" (per RFC2068) of the URI is really describing the
"IPP" resource in question, and this part cannot be modified by proxies. I
really don't care if the other fields are modified, just as long as it
reaches the intended origin server. If we have to remove the MUST in the
PRO document that talks about the IPP-URI MUST match the requestURI, then
so be it. It's a cheap change (IMHO) and I think we can live without it.
Randy
At 08:42 PM 6/9/98 -0700, Josh Cohen wrote:
>>>> -----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.
>