IPP Mail Archive: Re: IPP> notification methods

Re: IPP> notification methods

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

  • Next message: Jay Martin: "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 - 15:24:51 EDT