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