Jay-
I thought it was obvious that I was only talking about those users that
want to receive notifications via INDP. Of course, if users receive
notifications via some other delivery method, then they don't need to run
an INDP server.
The only exception I can think of is the case where multiple users share
one machine (on multiple terminals attached to one host, for example).
Then a single INDP server might support multiple users. However, I don't
think this is a common enough case to affect the argument. (Gone are the
days of 600 users on 600 3270s logged into one IBM mainframe!)
-Carl
Jay Martin <jkm@underscore.com> on 08/04/2000 01:18:05 PM
Please respond to jkm@underscore.com
To: Carl Kugler/Boulder/IBM@IBMUS
cc: ipp@pwg.org
Subject: 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 - 16:09:36 EDT