IPP Mail Archive: Re: IPP> notification methods

Re: IPP> notification methods

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

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

    Carl-

    Sorry, but perhaps my question wasn't focused properly. ;-)

    There's no issue about the definition of a "server", but
    rather the rational for stating that a single server must
    exist for each and every user.

            ...jay

    kugler@us.ibm.com wrote:
    >
    > Jay-
    >
    > I'm using the word "server" in its classic TCP/IP sense. From
    > Internetworking with Tcp/ip, Volume 1, by Comer, Douglas E:
    >
    > The term SERVER applies to any program that offers a service that can
    > be reached over the network.
    > Servers accept requests that arrive over the network, perform their
    > service, and return the result to the requester...
    >
    > A server starts execution before interaction begins and (usually)
    > continues to accept requests and send responses without ever terminating. A
    > client is any program that makes a request and awaits a response...
    >
    > A server waits for requests at a well-known port that has been
    > reserved for the service it offers. A client allocates an arbitrary,
    > unused, nonreserved port for its communication...
    >
    > Servers are usually more difficult to build than clients because, even
    > though they can be implemented with application level programs, servers
    > must enforce all the access and protection policies of the computer system
    > on which they run, and they must protect themselves against all possible
    > errors.
    >
    > The INDP "user agent" (possibly part of an IPP "client" application) is
    > actually a HTTP/TCP/IP server.
    >
    > -Carl
    >
    > Jay Martin <jkm@underscore.com> on 08/04/2000 12:15:16 PM
    >
    > Please respond to jkm@underscore.com
    >
    > To: Carl Kugler/Boulder/IBM@IBMUS
    > cc: ipp@pwg.org
    > Subject: 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 - 15:31:23 EDT