David,
Many thanks for the consideration.
1. I may be getting confused with the terminology. PSI defines three types of entities all of which have "Client" capability. From Figure 1 in the Developer's Guide, lets call the user client the "Mobile Device". So one has:
Mobile Device - with a client capability
Print Service -
Client Capability
QueryEndpointsInterface
ServiceCapabilitiesInterface
JobControlInterface
TargetDeviceSupportInterface
TargetDevice-
Client Capability
JobControlInterface
QueryEndpointsInterface
ServiceCapabilitiesInterface
a. if there are no firewalls (or all components are inside a common network), there should be no problem using the psi-port communicating from any client to any interface
b. in any case involving firewalls, any "server" interface needs special firewall handling, regardless of what port is used.
c. a mobile device may very well be trying to communicate to the Print Service through a foreign firewall, which does not support the PSI Port. So allowing the Mobile client a port 80 backup is highly desirable.
d. it would seem that a target device might want to operate in only the client mode. (This appears to be in violation of the requirement that the target device support all interfaces, but it is an attractive capability regardless) The target therefore could pull jobs from a internet Print Service to which it subscribed. This would allow "internet printing" without needing special firewall handling for the Target Device. The need to provide special firewall handing is one reason why IPP has not become a widely used "internet" printing protocol. Allowing the target device to pull jobs from a server that can be accessed via the internet would resolve this problem.
But from your statement that "A Target Device shall implement PSI only on port psi-port", it is not clear to me that you are allowing the client in the target device to initiate a connection on port 80.
I also do not understand your statement that:
"If an administrator chooses to expose their print service on port 3700,
then all traffic to it will be on 3700."
2. With respect to my comment about MIS not allowing a printer to communicate with an external server, the operative words here are "without adding more restrictions". And when I made the statement, I did indicate the restrictions that were required in the WBMM context. I believe that in defining the interface that the printer will use in this context, you are defining the restrictions. That is, you are limiting the printer contacts and what can transpire between the printer and the service or client. I believe that this will be acceptable to most enterprises, although it may be necessary in some implementations to allow configuration of more constraints, such as not supporting some interfaces, requiring authentication or encryption and possibly disallowing certain operations.
Regards,
Bill Wagner/NetSilicon.
-----Original Message-----
From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com]
Sent: Friday, February 28, 2003 9:51 AM
To: 'imcdonald@sharplabs.com'; Wagner,William; BERKEMA,ALAN C
(HP-Roseville,ex1)
Cc: 'ps@pwg.org'
Subject: PSI and Port 80, and printers traversing the firewall
Hi Bill...
A couple of questions for you... You mentioned the following with regards
to PSI and port 80:
<bill>
I am very sad to hear that PSI will not use port 80; I think that will very
much handicap the potential of what is an excellent capability. Of course,
IPP was assigned port 631, but many implementations still listen on port 80
as well.
</bill>
In consideration of this, Ira and I spent some time looking at PSI, and the
use of port 80, and port 3700 (psi-port), and came up with the following
proposal:
* A Print Service shall implement PSI on psi-port, and port 80 (and thus,
the path to ALL psi interfaces must be of the form
pwg-psips://server/psi/...)
* A Target Device shall implement PSI only on port psi-port
* A Client shall always try to communicate with a Print Service on psi-port
first, and if that fails, then utilize port 80.
We believe that this reasoning enables the following requirements:
1) A company can deploy a PSI Print Service on their normal, publically
exposed web-server on port 80.
2) All communication to a Target Device is on port 3700 for network
monitoring purposes.
3) Within and enterprise, communication between a client and a Print
Service is on 3700 for network monitoring purposes.
4) If an administrator chooses to expose their print service on port 3700,
then all traffic to it will be on 3700...
Do you feel that this addresses your concerns? (And your customers?)
Second:
<bill>
Having been though this at various places. Asking if they would allow a
printer that talks to an external server, without adding more restrictions,
will get a very quick NO.
</bill>
This model is very important for many of the PSI firewall traversing use
models! I do think that implementers of Target Devices should not have
their printers come configured "out of the box" with the ability to go and
fetch data from an external server. This should probably be something that
the administrator needs to enable for particular printers within their
enterprise. However, once allowed by the administrator, these "public
printers" would then be able to retrieve publically initiated print jobs.
Another option is to only allow "authorized users" to initiate these
out-bound requests. This would be accomplished by authenticating the user
via http, and then the Target Device would need to authorize the user
against an acl..
Comments??
Dave
This archive was generated by hypermail 2b29 : Mon Mar 03 2003 - 11:19:46 EST