Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests

From: Randy Turner <[email-masked]>
Date: Tue, 09 Jun 1998 22:56:36 -0700

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:[email-masked]]
>> Sent: Tuesday, June 09, 1998 8:13 PM
>> To: Paul Moore; 'Tom Hastings'
>> Cc: 'Carl Kugler'; [email-masked]
>> 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.
>

---

From: James Walker <[email-masked]>
Date: Wed, 10 Jun 1998 07:45:48 -0500

Randy Turner wrote:
> ...

I also got the impression from comments made in this discussion that
there was some advantage for a user to be able to look at an URL and
somehow "know" that it was an IPP thing rather than just some web
page.  Thus, Larry's ipp: scheme idea (which gets translated at the
client side to http://<server>:<ipp port>/) seems attractive.

Personally, I think that both of these ideas provide useful
functionality, and we should consider both of them.  That is,
use the ipp: scheme (which the client translates to http:),
and use a new PRINT method.

one man's thoughts...
...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 10 Jun 1998 08:26:20 PDT

Actually, I realize that if TLS is mandatory for IPP, then
"ipp://host.dom/path" gets turned into "https://host.dom:432/path",
i.e., assuming a secure transmission.

Larry
--
http://www.parc.xerox.com/masinter

---

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 10 Jun 1998 09:11:49 PDT

>i.e., assuming a secure transmission.

Larry,

We will discuss this with Keith. He thinks otherwise.

Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]