Printer Services Mail Archive: PS> PSI and Port 80, and prin

PS> PSI and Port 80, and printers traversing the firewall

From: HALL,DAVID (HP-Vancouver,ex1) (dhall@hp.com)
Date: Fri Feb 28 2003 - 09:50:45 EST

  • Next message: Mike Haller: "PS> Difficulty with AddDocumentByPost"

    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 : Fri Feb 28 2003 - 09:51:07 EST