Printer Services Mail Archive: PS> [PSI]: additional number;

PS> [PSI]: additional number; next call 03/11/03

From: BERKEMA,ALAN C (HP-Roseville,ex1) (alan.berkema@hp.com)
Date: Mon Mar 10 2003 - 12:15:15 EST

  • Next message: HALL,DAVID (HP-Vancouver,ex1): "PS> New PSI 1.0 Working Draft 20030310 Available"

    -----Original Message-----
    From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan.berkema@hp.com]
    Sent: Wednesday, March 05, 2003 3:45 PM
    To: 'a PSI pwg.org'
    Subject: PS> [PSI]: minutes03/04/03; next call 03/11/03

    Teleconference details:

    NEXT: Tuesday March 11 2003 (USA)

    Time: 8 AM (US PST)

    Number: 866-639-4738
    Participant PIN: 7855605

    If Trouble with Above Try:
    Toll Access Number:
                574-935-6700
    Participant PIN: 7855605

    Agenda:
    1) Alain's e-mail Questions
    2) addDocumnetByPush review
    3) Ready for Last Call
    4) ?

    Meeting 03/04/03

      PSI Working Group:
      *Alan Berkema *Dave Hall Gail Songer
      -Jerry Thasher *Harry Lewis *Ted Tronson
      *Peter Mierau *Peter Zehler Paul Tykodi
       Bob Taylor Don Levinstone Lee Farrell
       Don Wright Kirk Ocke *Ira Mcdonald
       Amir Shahindoust *Alain Regnier *Mike Haller
      
      * = attendance
     
    Agenda:
    1) PSI Port vs. Port 80
    2) Difficulty with AddDocumentByPost
    3) Alternate transport?
    4) Alain's questions
    5) Ready for Last Call

    Minutes:

    1) Some desire to use PSI over port 80, some existing web servers
    and small office may only expose port 80.

    The psiport allows all trafiic to routed through this port and
    has load balancing advantages. Seperate accounting and security is also
    an advantage. See Ira's past discussion on Dynamic vs. Static ports at the
    end of these minutes for additional info.

    Summary:
    PSI devices will try the psiport first and this is the preffered port.
    Port 80 may be used as a last resort if the psiport fails.
    Port number 55559 will be used as the proto type port until we get an
    IANA number.

    2 & 3) addDocumentByPost was changed to addDocumentByPush.
    This is followed by an HTTP PUT for data transfer *OR*
    a pushDocument method which passes the data by value,
    the data type is restricted to bin64 encoding
    PushDocument (documentURI : URI, documentData : base64Binary) : void

    The closeJob() method will replace the lastDocument flag in the
    addDocument* methods. This fixes a lot of logical holes.
    Much discussion about the error code for when a closeJob() occurs before
    all data has actually been transferred. I think
    "clientErrorDataPending" may be in the lead however, sequence error
    was a contender at one point.

    Need to carefully review all exception codes.

    4) Alain's questions
    Even after running over time by close to an hour we did
    not get to this, it's up first next time.

    5) Schedule will discuss "last call" readiness at next call
    Not ready yet, however, the pending "last call" seems to be getting
    folks to voice some needed improvements.

    Thanks,
    Alan

    -----------------
    WebEx info:
    -------------------------
    FIRST TIME USERS
    -------------------------
    For fully interactive meetings, including the ability
    to present your documents and applications, a one-time
    setup takes less than 10 minutes. Click this URL to set up now:
    https://hp.webex.com/join/
    Then click New User.
    -------------------------
    MEETING SUMMARY
    -------------------------
    Name: PSI
    Time: 8:00AM, (GMT -08:00) Pacific Time, USA & Canada
    Meeting Number: 27995593
    Meeting Password: newpsi
    Host: Alan Berkema
    1(916)7855605

    ----------------------------------------------------------------------------
    -

    PSI interfaces SHOULD have a static port (IANA-registered by vendor 'PWG')
    that is always the PSI listen port.

    PSI interfaces SHOULD NOT use dynamic ports (even by protocol agreement
    during PSI WSDL sessions), because:

    1) Firewalls and NAT (Network Address Translator) systems assume that
        all protocols allowed to pass (traverse the domain boundary) use
        static IANA-registered ports (permission rules are normally based
        on a specific application protocol over a specific numbered port).
        Firewalls/NATs often implement ALGs (Application Layer Gateways)
        that enforce fine-grained permission rules. But the premise is
        always that the protocol on a given port is INVARIANT, and is
        determined by the port number (FTP proxies are fundamentally
        dangerous, for this reason).

        Dynamic ports completely defeat ALGs and firewall permissions
        (thus destroying the 'security perimeter' of the firewall).

        (There are a series of horrible exceptions in ALGs around HTTP
        port 80, due to other 'hidden' application protocols - PSI should
        not go there...)

    2) Boundary routers (between enterprise and public networks) and
        core routers (within the Internet backbone) manage quality of
        service and packet delivery by 'aggregating' destinations
        (host/port pairs) for routing decisions.

        Dynamic ports completely defeat traffic 'aggregation' (because
        the router has no way to know that the alternate port traffic
        is associated with the original static port traffic).

        Routers also block all ports that are not specifically
        authorized to cross a domain boundary (in one direction or
        the other - not necessarily both) in their permission rules.
        Dynamic ports simply won't work in the general case.

    Hope this helps.

    Cheers,
    - Ira McDonald
      High North Inc



    This archive was generated by hypermail 2b29 : Mon Mar 10 2003 - 12:15:46 EST