IPP Mail Archive: Re: IPP> notification methods

IPP Mail Archive: Re: IPP> notification methods

Re: IPP> notification methods

From: Jay Martin (jkm@underscore.com)
Date: Fri Aug 04 2000 - 14:15:16 EDT

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

    Carl,

    Would it be possible for you to *briefly* explain to the list
    why INDP requires "a server per user"? Some of us are a bit
    confused by this. Perhaps the definition of "server" varies
    amongst some of us. Thanks,

            ...jay

    kugler@us.ibm.com wrote:
    >
    > 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 - 14:26:11 EDT