> a) Does every "IPP printer" have to be made known to the firewall(s)?
I move we do not spend much time trying to address inbound (thru the
firewall) issues. It is a very complex problem and companies
and firewall vendors will all want to approach it differently.
My approach would be either no internal printers visible to outside,
or a special IPP relay outside the firewall that would appear to be
the printer outside and either store and forward or actually talk to
the printer in realtime on the inside.
> b) I did see (in the archives) that there was some discussion about
> decisions based on the port number. An application-level firewall
> (proxy) would be needed to distinguish between http intended for a
> web server and http intended for an ipp printer. The security
Not necessarily. The URL and hence server for IPP could (should?) be
entirely seperate from the normal web server the company uses for
their "home page".
> c) How would we handle the case where a (small) business has only a
> PPP link to the Internet via some ISP. The web hosting is provided
> by the ISP and resides at the ISP's site. How exactly would a job
> be received in the IPP printer at this business? We could assume
> that the link is always up. This appears to place some requirement
> on the part of the ISP --- to route some of the http traffic
> (which contains IPP) to the client (business) site.
This is very interesting. If the link is up all the time then the
printer (or print server) could have a URL of its own. Whomever is
trying to print to that printer would be using the printer URL and
not the general ISP URL. Sure, it may be an IP address if the
printer doesn't appear in the DNS namespace, but that works fine.
Another approach (which doesn't require a dedicated link) would be
similar to that used by e-mail today. The ISP could receive and
store print jobs for the small company and the company would connect
periodically and suck down the jobs.
sdb
| Sylvan Butler | sbutler at boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |