IPP Mail Archive: RE: IPP> TES: Mandatory IPP notification a

IPP Mail Archive: RE: IPP> TES: Mandatory IPP notification a

RE: IPP> TES: Mandatory IPP notification agreement

From: don@lexmark.com
Date: Fri Jun 23 2000 - 12:30:37 EDT

  • Next message: don@lexmark.com: "IPP> "Discussions" (read arguments) over e-mail"

    Peter said:

    >A concern I have with Carl's proposal is that it assumes the notification
    >recipient is always going to be the submitter of the print job.

    I agree!!

    I have made this point too many times and no one has an answer. Both the
    receipient of the print job (this is INTERNET Printing) and the "Key Operator"
    need to here about events. Although different, these requirements are pretty
    major from my perspective.

    **********************************************
    * Don Wright don@lexmark.com *
    * Chair, Printer Working Group *
    * Chair, IEEE MSC *
    * *
    * Director, Strategic & Technical Alliances *
    * Lexmark International *
    * 740 New Circle Rd *
    * Lexington, Ky 40550 *
    * 859-232-4808 (phone) 859-232-6740 (fax) *
    * (Former area code until 10/1 was 606) *
    **********************************************

    Peter.Zehler%usa.xerox.com@interlock.lexmark.com on 06/23/2000 12:27:24 PM

    To: harryl%us.ibm.com@interlock.lexmark.com, Don_Wright/Lex/Lexmark@LEXMARK
    cc: henrik.holst%i-data.com@interlock.lexmark.com,
          ipp%pwg.org@interlock.lexmark.com,
          Peter.Zehler%usa.xerox.com@interlock.lexmark.com,
          Private_User@interlock.lexmark.com,
          jkm%underscore.com@interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
    Subject: RE: IPP> TES: Mandatory IPP notification agreement

    All,

    I would prefer to see a mandated event be sent by the printer at INDP
    subscription time. The notification recipient would then be in a position
    to determine if the recipient's infrastructure allows programmatic
    notification. Steps may then be taken to provide a user friendly solution
    (e.g. inform user, allow user to select email).

    A concern I have with Carl's proposal is that it assumes the notification
    recipient is always going to be the submitter of the print job.

    Pete

                        Peter Zehler
                        XEROX
                        Xerox Architecture Center
                        Email: Peter.Zehler@usa.xerox.com
                        Voice: (716) 265-8755
                        FAX: (716) 265-8792
                        US Mail: Peter Zehler
                                Xerox Corp.
                                800 Phillips Rd.
                                M/S 139-05A
                                Webster NY, 14580-9701

    -----Original Message-----
    From: harryl@us.ibm.com [mailto:harryl@us.ibm.com]
    Sent: Friday, June 23, 2000 12:06 PM
    To: don@lexmark.com
    Cc: henrik.holst@i-data.com; ipp@pwg.org; Peter.Zehler@usa.xerox.com;
    Private_User@lexmark.com; jkm@underscore.com
    Subject: RE: IPP> TES: Mandatory IPP notification agreement

    Carl's original proposal was for event notif over persistent connection
    which resulted from using IPP to print the job (i.e. "native") with asych
    events facilitated by MIME Multipart/Mixed. Criticism was that connections
    may have to persist for too long a period under circumstances were, for
    example, the printer has an internal spool. My proposal addressed that
    concern by adding "server directed" polling to help determine when it is
    appropriate to establish the persistent connection. Ultimately, while the
    job is printing (i.e. when it matters, pages are stacking, jams occur
    etc.) this is still an event driven notification scheme. The "server
    directed" nature of this solution is intended to optimized the polling vs.
    selecting some arbitrary periodic rate. I'm not sure exactly what the
    issue is with combining two effective means to achieve overall
    optimization?

    Harry Lewis
    IBM Printing Systems

    don@lexmark.com
    06/23/2000 09:50 AM

            To: Harry Lewis/Boulder/IBM@IBMUS
            cc: Private_User@lexmark.com, henrik.holst@i-data.com,
    ipp@pwg.org,
    Peter.Zehler@usa.xerox.com
            Subject: RE: IPP> TES: Mandatory IPP notification agreement

    Polling is pollings. Notification is asynchronous.

    Do you ask the postman everyday if you have mail and if you do you go get
    it?
    No. The mail is brought to you whether you know it is coming or not.
    ANYTHING
    that requires the client to actively pursue getting the state of the print
    job
    is POLLING.

    **********************************************
    * Don Wright don@lexmark.com *
    * Chair, Printer Working Group *
    * Chair, IEEE MSC *
    * *
    * Director, Strategic & Technical Alliances *
    * Lexmark International *
    * 740 New Circle Rd *
    * Lexington, Ky 40550 *
    * 859-232-4808 (phone) 859-232-6740 (fax) *
    * (Former area code until 10/1 was 606) *
    **********************************************

    harryl%us.ibm.com@interlock.lexmark.com on 06/23/2000 11:41:16 AM

    To: Don_Wright/Lex/Lexmark@LEXMARK
    cc: henrik.holst%i-data.com@interlock.lexmark.com,
          ipp%pwg.org@interlock.lexmark.com,
          Peter.Zehler%usa.xerox.com@interlock.lexmark.com (bcc: Don
          Wright/Lex/Lexmark)
    Subject: RE: IPP> TES: Mandatory IPP notification agreement

    NO!

    What Henrik describes was contained in my high-level proposal which
    combined synchronous, "server directed polling" with a final, "print
    eminent" persistent connection flowing asynchronous events.

    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/Simple_IPP_Notification.pdf

    This proposal addressed the issue of long persistent connections but kept
    the protocol "native" (using HTTP from client to IPP printer). The main
    criticism was the potential for a proxy to cache (bundle) events that
    flowed during the asynchronous period. Not sure why this concern was
    viewed any greater than the firewall issues plaguing other methods.

    I'm not "against" INDP or Mail. I think they both have great merit. I do
    feel we have fallen short of describing and prescribing a simple, native
    (utilizing existing IPP infrastructure), mandatory (read interoperable)
    notification method. If we don't think lack thereof will create interop
    issues... just reflect on the difficulty we're having to determine how to
    conduct a successful notification bakeoff!

    Harry Lewis
    IBM Printing Systems

    don@lexmark.com
    Sent by: owner-ipp@pwg.org
    06/23/2000 06:03 AM

            To: henrik.holst@i-data.com
            cc: Peter.Zehler@usa.xerox.com, ipp@pwg.org
            Subject: RE: IPP> TES: Mandatory IPP notification agreement

    I bet all the Firewall Admins will love all those persistant connections
    (hours
    long?) through their firewalls.

    **********************************************
    * Don Wright don@lexmark.com *
    * Chair, Printer Working Group *
    * Chair, IEEE MSC *
    * *
    * Director, Strategic & Technical Alliances *
    * Lexmark International *
    * 740 New Circle Rd *
    * Lexington, Ky 40550 *
    * 859-232-4808 (phone) 859-232-6740 (fax) *
    * (Former area code until 10/1 was 606) *
    **********************************************

    henrik.holst%i-data.com@interlock.lexmark.com on 06/23/2000 07:48:13 AM

    To: Peter.Zehler%usa.xerox.com@interlock.lexmark.com
    cc: ipp%pwg.org@interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
    Subject: RE: IPP> TES: Mandatory IPP notification agreement

    Maybe it would help a lot if we had a method which use HTTP as transport,
    but the
    client did the connection to the server and the server could send
    notification event
    on this connection. The client don't poll the server, but gets
    asynchronous
    events
    from the server.
    This would of course only work if the notification subscriber and
    the notification recipient is the same.

    Any comments?

    Henrik

    "Zehler, Peter" <Peter.Zehler@usa.xerox.com>@pwg.org on 23-06-2000
    13:16:15

    Sent by: owner-ipp@pwg.org

    To: henrik.holst@i-data.com, ipp@pwg.org
    cc:

    Subject: RE: IPP> TES: Mandatory IPP notification agreement

    All,

    Another problem I have with a notification mechanism that uses HTTP in the
    other direction (i.e. printer to client) is that it is difficult for the
    print client to discover if his infrastructure will permit the
    communication. How will the client check to see if notification is
    possible
    to his location on the Internet? The only ways I know are prior knowledge
    or to poll the printer to see if you miss an event.

    For this reason, and others, I am in favor of mandating email. I want to
    finish up INDP so it may be tested at the Bake-Off along with email. INDP
    will be useful when we really start working on QUALDOCS. I would hope
    that
    "mailto://" and "indp://" would both be valid in notification
    registrations.
    Let the customer decide which is appropriate a given circumstance.

    Pete

                        Peter Zehler
                        XEROX
                        Xerox Architecture Center
                        Email: Peter.Zehler@usa.xerox.com
                        Voice: (716) 265-8755
                        FAX: (716) 265-8792
                        US Mail: Peter Zehler
                                Xerox Corp.
                                800 Phillips Rd.
                                M/S 139-05A
                                Webster NY, 14580-9701

    -----Original Message-----
    From: henrik.holst@i-data.com [mailto:henrik.holst@i-data.com]
    Sent: Friday, June 23, 2000 4:02 AM
    To: ipp@pwg.org
    Subject: Re: IPP> TES: Mandatory IPP notification agreement

    I just think it's really strange if we describe an Internet Printing
    Protocol but the
    mandatory notification method won't work in 99% of the user cases!

    Henrik

    don@lexmark.com@pwg.org on 22-06-2000 22:16:34

    Sent by: owner-ipp@pwg.org

    To: kugler@us.ibm.com
    cc: ipp@pwg.org

    Subject: Re: IPP> TES: Mandatory IPP notification agreement

    Just because there are cases where a machine can't get notifications does
    not
    mean we should not standardize it. By making it mandatory, developers of
    products must support it. It doesn't mean that everyone must use it.
    (BTW: I
    am also in favor of making e-mail mandatory).

    **********************************************
    * Don Wright don@lexmark.com *
    * Chair, Printer Working Group *
    * Chair, IEEE MSC *
    * *
    * Director, Strategic & Technical Alliances *
    * Lexmark International *
    * 740 New Circle Rd *
    * Lexington, Ky 40550 *
    * 859-232-4808 (phone) 859-232-6740 (fax) *
    * (Former area code until 10/1 was 606) *
    **********************************************

    kugler%us.ibm.com@interlock.lexmark.com on 06/22/2000 04:13:36 PM

    To: Don_Wright/Lex/Lexmark@LEXMARK
    cc: (bcc: Don Wright/Lex/Lexmark)
    Subject: Re: IPP> TES: Mandatory IPP notification agreement

    Many firewalls allow you to connect many more machines to the Internet
    than
    you have IP addresses for. The addresses behind the firewall may be
    private, unregistered addresses, not globally routable, not globally
    unique.

         -Carl

    don@lexmark.com on 06/22/2000 01:40:16 PM

    To: Carl Kugler/Boulder/IBM@IBMUS
    cc:
    Subject: Re: IPP> TES: Mandatory IPP notification agreement

    Firewalls are configurable.

    Don

    kugler%us.ibm.com@interlock.lexmark.com on 06/22/2000 03:33:16 PM

    To: Don_Wright/Lex/Lexmark@LEXMARK
    cc: ipp%pwg.org@interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
    Subject: Re: IPP> TES: Mandatory IPP notification agreement

    Will go through OUTBOUND from a Printer INSIDE to a client OUTSIDE. But
    what if the CLIENT is behind a firewall?

         -Carl

    don@lexmark.com on 06/22/2000 12:04:27 PM

    To: Carl Kugler/Boulder/IBM@IBMUS
    cc: ipp@pwg.org
    Subject: Re: IPP> TES: Mandatory IPP notification agreement

    In the matter of INDP and firewalls, INDP WILL go through a properly
    configured
    firewall. It won't go through one that blocks on whatever port we are
    assigned.

    Let's be accurate.

    **********************************************
    * Don Wright don@lexmark.com *
    * Chair, Printer Working Group *
    * Chair, IEEE MSC *
    * *
    * Director, Strategic & Technical Alliances *
    * Lexmark International *
    * 740 New Circle Rd *
    * Lexington, Ky 40550 *
    * 859-232-4808 (phone) 859-232-6740 (fax) *
    * (Former area code until 10/1 was 606) *
    **********************************************

    kugler%us.ibm.com@interlock.lexmark.com on 06/21/2000 06:08:52 PM

    To: ipp%pwg.org@interlock.lexmark.com
    cc: (bcc: Don Wright/Lex/Lexmark)
    Subject: Re: IPP> TES: Mandatory IPP notification agreement

    [Added subject line and this P.S.:]

    henrik.holst@i... wrote:
    >
    > Well it was my understanding that we didn't agree on a mandatory method.
    > And the INDP method
    > won't go through a firewall, so if you are searching for a mandatory
    method
    > I would say MAILTO.

    I agree, INDP won't go through firewalls.

    ---------------------- Forwarded by Carl Kugler/Boulder/IBM on 06/21/2000
    04:07 PM ---------------------------

    From: Carl Kugler on 06/21/2000 03:39 PM

    To: ipp@pwg.org
    cc:
    From: Carl Kugler/Boulder/IBM@IBMUS
    Subject:

    "Zehler, Peter" <Peter.Zehler@u...> wrote:
    ...
    > My preference is that INDP be mandated. I feel that programmatic
    > notification is critical to the development of robust IPP applications.
    One
    > of those applications would be QUALDOCS. In the definition of IPP, and
    its
    > associated notification mechanism, I am concerned primarily with client
    > /server communications. End user notification, while useful, is not my
    > primary objective. It is true that infrastructure will have to be
    > configured to allow this traffic to pass. The same is true of outbound
    IPP
    > requests. I imagine that most of our printers will also implement
    mailto.
    I
    > have no objections to allowing both, but I think only one should be
    > mandated.
    >
    ...

    Actually, in many cases the infrastructure does not have to be configured
    to allow outbound IPP requests. I've always been able to connect to IPP
    Printers on the Internet with an IPP client here inside the IBM firewall.
    (In fact, I remember connecting my client to your Printer a few years
    ago!)
    We run a SOCKS Internet gateway here, and I can make a TCP connection to
    any host:port on the Internet.

    "McDonald, Ira" <imcdonald@s...> wrote:
    ...
    > Lastly, Peter you jumped from port filtering by firewalls
    > to MIME type filtering - but the latter requires that the
    > firewall have an Application Layer Gateway (ALG) to figure
    > out the protocol and THEN to find the MIME type inside the
    > protocol envelope.
    >
    > Personally, I agree with Henrik about selecting email as
    > the IPP mandatory notification method.
    >

    Most firewalls allow insiders to make outbound connections (perhaps
    indirectly), but prevent outsiders from making inbound connections. Very
    few corporate firewall administrators would be willing to simply open a
    port and allow anybody to make inbound connections to arbitrary addresses
    inside the firewall. Here at IBM, making an inbound connection requires
    full-blown authentication, encryption, one-time passwords, etc. (by
    strictly enforced corporate policy). We use Aventail for this. Also, in
    many cases, machines inside a firewall are simply not addressable from
    outside, due to network address translation (NAT), IP Masquerading,
    Windows
    connection sharing, etc. You'd need a really sophisticated
    application-level gateway to deal with these issues.

         -Carl



    This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 12:40:42 EDT