Subject: RE: IPP> Re: Implications of introducing new scheme and port

From: Josh Cohen <[email-masked]>
Date: Tue, 9 Jun 1998 12:40:46 -0700

so then would the advice that we give
to proxy admins to filter/allow IPP to 
watch for URLs on port XXX ?

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]]
> Sent: Tuesday, June 09, 1998 12:28 PM
> To: Carl-Uno Manros
> Cc: Keith Moore; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: IPP> Re: Implications of introducing new scheme and port 
> 
> 
> I've been thinking about the interaction of an ipp: URL and 
> the installed base of proxies that support http: but will not
> understand ipp:
> 
> Whenever an IPP client is configured to use a proxy, it would probably
> make sense to have the client send 
> "POST http://foo.bar:XXX/zot HTTP/1.1" to the proxy when attempting
> to talk to the ipp object "ipp://foo.bar/zot".
> 
> As far as I can tell from a very casual analysis, this is the only
> place where it would be necessary to actually send the string "http:"
> to refer to a ipp object.  Every other URI that refers to a ipp object
> could use "ipp:" instead.
> 
> I don't see a problem with doing things this way, as long as it's
> clearly documented.  Perhaps it would be wise to add a section called
> something like "Tunneling of IPP requests over HTTP proxies" to the
> protocol document that specified such details.
> 
> Keith
> 
> 
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 09 Jun 1998 15:48:44 -0400

> watch for URLs on port XXX ?

In my example, XXX is the reserved IPP port.  So if the admins want to
block outgoing IPP traffic, they tell their routers or firewalls to 
not transmit requests to anything on port XXX.

Of course, anyone with an HTTP server on port XXX will be unreachable
from behind such a firewall, and the filter won't block access to IPP 
servers on other ports.  But that's an inherent limitation of firewalls - 
they can't really filter out all unwanted traffic, they can only filter
out most of it. 

As long as IPP is run on a separate port, I'm pretty ambivalent 
about PRINT vs. POST.

Keith

---

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 9 Jun 1998 13:10:08 PDT

>As long as IPP is run on a separate port, I'm pretty ambivalent 

Keith,

I assume in this discussion that port XXX is the DEFAULT port for IPP,
but as in other schemes, you can override it by specifying an explicit 
port number in the URL, including port 80.

Is this understanding correct, and if so does it open a way for people
to still go around the new IPP port number definition? The administrator
could always set up the IPP Printer to ignore anything that does not 
come in over port XXX.

If we go down the IPP port lane, I think we need to specify that new 
IPP Printers should come out of the box pre-configured to the IPP 
default port. The biggest problem security admins have is that people
just take new equipment out of the box, plug them in, and if it
works, never try to reconfigure them.

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]

---

From: Keith Moore <[email-masked]>
Date: Tue, 09 Jun 1998 16:22:45 -0400

> default port. 

I agree.

Keith