Dave,
The clarification is appreciated.
However, I still seem to be missing something on:
"If an administrator chooses to expose their print service on port 3700,
then all traffic to it will be on 3700."
<dave>
Give the client "rule" that clients must try 3700 first, and then 80 - if a
Print Service is exposed on 3700, then all PSI method invocations from
clients will be on port 3700. I added this comment into the specification
so that implementers / deployers understand that 3700 may be the only thing
available.
</dave>
Doesn't that conflict with the proposal that
"A Print Service shall implement PSI on psi-port, and port 80 ", which suggests that the print service must listen on both ports.
And, given the instance where the mobile client cannot get through the firewall at his location via the PSI-port, should not the print service also listen on port 80?
Thanks,
Bill Wagner
-----Original Message-----
From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com]
Sent: Monday, March 03, 2003 11:38 AM
To: Wagner,William; HALL,DAVID (HP-Vancouver,ex1);
imcdonald@sharplabs.com; BERKEMA,ALAN C (HP-Roseville,ex1)
Cc: ps@pwg.org
Subject: RE: PSI and Port 80, and printers traversing the firewall
Hi Bill and All...
See comments inline below..
Dave
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
<dave>
Yep, the client term is difficult to nail down. I'll see if I can be more
explicit in the following comments..
</dave>
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.
<dave>
Yep, exactly - the PSI "server" interfaces on a Print Service, and the PSI
"server" interfaces on a Target Device.
</dave>
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.
<dave>
This is the hope that by allowing a PSI Print Service to also expose PSI
"server" interfaces over port 80 will allow for more deployment scenarios
that if we restricted it to only 3700
</dave>
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.
<dave>
A true PSI Target Device does indeed need to implement the "server"
interfaces. However, I don't believe that there is anything precluding
vendors from implementing only the "client" side of a Target Device. This
implementation of a Target Device simply makes the Target Device look like
it is behind a firewall from the Print Services "client" perspective. This
is a similiar situation to the "Bluetooth Target Device Proxy" where the
handheld pretends to be a "Target Device" and pulls the data from the Print
Service, and then pushes it to the printer via BlueTooth.
</dave>
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.
<dave>
I think that the intention here is that a Target Device shall implement the
PSI "server" set of interfaces only on port psi-port. The "client" side of
the Target Device should behaive as per the client rules - try 3700 first,
then 80.
</dave>
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."
<dave>
Give the client "rule" that clients must try 3700 first, and then 80 - if a
Print Service is exposed on 3700, then all PSI method invocations from
clients will be on port 3700. I added this comment into the specification
so that implementers / deployers understand that 3700 may be the only thing
available.
</dave>
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.
<dave>
Yep, exactly. This makes a lot of sense.
</dave>
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:49:52 EST