IPP Mail Archive: Re: IPP> notification methods

Re: IPP> notification methods

From: kugler@us.ibm.com
Date: Fri Aug 04 2000 - 16:40:03 EDT

  • Next message: don@lexmark.com: "Re: IPP> notification methods"

    Me and 99% of other end users in the real world. INDP over the Internet is
    not impossible, just impractical.

         -Carl

    don@lexmark.com on 08/04/2000 02:16:05 PM

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

    Then it sounds like YOU will have to live with e-mail while others can
    enjoy
    INDP.

    **********************************************
    * 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 08/04/2000 04:14:07 PM

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

    Our firewall admins insist on more than hope. One bad (broken,
    misconfigured, back-doored, ...) INDP server, of possibly thousands in the
    enterprise, would be enough to lay open the whole corporate network if the
    firewall were to allow inbound connections. INDP inbound through the
    firewall would never fly here, that's for sure.

    There are other virtually insurmoutable problems. Most Internet client
    hosts are simply not addressable as servers (because of network-address
    translation, proxies, SOCKS, dynamically-assigned addresses (e.g., DHCP or
    dial-up), etc). There probably wouldn't be enough Internet addresses to go
    around if they were.

         -Carl

    don@lexmark.com on 08/04/2000 01:21:50 PM

    To: Carl Kugler/Boulder/IBM@IBMUS
    cc: Private_User@lexmark.com, ipp@pwg.org
    Subject: Re: IPP> notification methods

    A well written INDP client that doesn't look at any other port and manages
    its
    buffers properly shouldn't have too many problems (we hope)!

    While we are on this subject; could someone explain to me the poor coding
    skills
    that seem to be associated with networking applications that allow input
    buffers
    to overflow. Geez, I learned not to let that happen decades ago writing
    embedded assembler code for typewriters. I know... blame it on the
    compilers!!

    **********************************************
    * 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 08/04/2000 03:16:00 PM

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

    I agree. Exposing all these HTTP servers on the Internet is the hard part.

         -Carl

    don@lexmark.com on 08/04/2000 12:38:37 PM

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

    I contend that addition of a subsetted HTTP server on the clients to catch
    INDP
    notifications would be included in the client application that handles the
    notication and would be a relatively small amount of code considering
    everything
    else the client application has to do.

    **********************************************
    * 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 08/04/2000 01:02:33 PM

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

    There is a huge PRACTICAL difference between mailto vs. indp: indp
    requires a server per user, mailto only requires a client. There is a
    great difference in cost, complexity, resource consumption, and security
    considerations between running a client on the Internet and deploying a
    server on the Internet. Most Internet servers are used by many users, so
    the cost is affordable. A server per user just won't scale to the
    Internet.

         -Carl

    --- In ipp@egroups.com, don@l... wrote:
    > The real difference between the use of mailto versus INDP is that mailto
    is for
    > a receipient who does not have an IPP/INDP enabled client or does not
    have it
    > running at the time the notification is to be received.
    >
    > **********************************************
    > * Don Wright don@l... *
    > * 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@i... on 07/26/2000 10:54:23 AM
    >
    > To: Don_Wright/Lex/Lexmark@LEXMARK
    > cc: ipp%pwg.org@i...,
    > pmoore%peerless.com@i... (bcc: Don Wright/Lex/Lexmark)
    > Subject: Re: IPP> notification methods
    >
    >
    >
    >
    >
    >
    > I accept that INDP may "work" in the Internet if properly configured.
    But,
    > in this case, you wouldn't necessarily need to mandate mailto for human
    > readable. So either association (mail/human - indp/machine OR
    mail/inter
    > - indp/intra) is equally flawed.
    >
    > Then... the only thing certain is that mailto is NOT intended for machine
    > readable. Why don't we just state that?
    >
    > Peter Z. has a suggestion for helping to determine what is supported.
    > > a notification... sent out at INDP registration... (that) allows a...
    > > recipient to determine if the infrastructure supports INDP...
    >
    > Harry Lewis
    > IBM Printing Systems
    >
    >
    >
    >
    > don@l...
    > Sent by: owner-ipp@p...
    > 07/26/2000 05:01 AM
    >
    >
    > To: Harry Lewis/Boulder/IBM@IBMUS
    > cc: pmoore@p..., ipp@p...
    > Subject: Re: IPP> notification methods
    >
    >
    > I fail to see the reason to ASSUME that every implementation of IPP
    > NOTIFICATION
    > will occur behind a firewall that is NOT configured to allow INDP
    > notifications
    > to pass through it. Any attempt to associate "mailto" or "indp"
    > EXCLUSIVELY
    > with either INTERnets or INTRAnets is flawed. If we would have used this
    > argument for IPP in the beginning we would have made statements like:
    >
    > 1. If a device is configured to print across the Internet it IS OUT OF
    > LUCK.
    > 2. If a device is configured to print in the context of an Intranet it
    > MUST
    > support IPP.
    >
    > Let's separate the issue of the INTERNET vs INTRANET context of these
    > delivery
    > services. When a customer decides they want these services, they will
    > configure
    > their firewalls (if present) to make it happen.
    >
    > **********************************************
    > * Don Wright don@l... *
    > * 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@i... on 07/26/2000 01:00:41 AM
    >
    > To: pmoore%peerless.com@i...
    > cc: ipp%pwg.org@i... (bcc: Don Wright/Lex/Lexmark)
    > Subject: Re: IPP> notification methods
    >
    >
    >
    >
    >
    >
    > I feel a more accurate way of looking at it is:
    >
    > 1. If a device is configured to provide event notification across the
    > Internet it MUST support mailto
    > 2. If a device is configured to provide event notification in the context
    > of an Intranet it SHOULD support INDP
    >
    > We could live with the proposal to bind human/mail vs. machine/indp.
    > However, this ignores the fact that INDP also handles human readable.
    >
    > Harry Lewis
    > IBM Printing Systems
    >
    >
    >
    >
    > pmoore@p...
    > Sent by: owner-ipp@p...
    > 07/20/2000 09:31 AM
    >
    >
    > To: ipp@p...
    > cc:
    > Subject: IPP> notification methods
    >
    >
    > Following the SF meeting I would like to formally propose the following.
    >
    > 1. If a device wants to expose human readable events then it MUST support
    > the
    > mailto method
    >
    > 2. If a device wants to expose machine readable events then it MUST
    > support the
    > INDP method
    >
    > But we do not UNCONDITIONALLY require either.
    >
    > (Now dons flame-proof clothing and awaits flaming)



    This archive was generated by hypermail 2b29 : Fri Aug 04 2000 - 16:50:46 EDT