A well written INDP client that doesn't look at any other port and manages its
buffers properly shouldn't have too many problems (we hope)!
While we are on this subject; could someone explain to me the poor coding skills
that seem to be associated with networking applications that allow input buffers
to overflow. Geez, I learned not to let that happen decades ago writing
embedded assembler code for typewriters. I know... blame it on the compilers!!
**********************************************
* Don Wright don at 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 at interlock.lexmark.com on 08/04/2000 03:16:00 PM
To: Don_Wright/Lex/Lexmark at LEXMARK
cc: ipp%pwg.org at interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
Subject: Re: IPP> notification methods
I agree. Exposing all these HTTP servers on the Internet is the hard part.
-Carl
don at lexmark.com on 08/04/2000 12:38:37 PM
To: Carl Kugler/Boulder/IBM at IBMUS
cc: ipp at 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 at 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 at interlock.lexmark.com on 08/04/2000 01:02:33 PM
To: ipp%pwg.org at 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 at egroups.com, don at 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 at 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 at i... on 07/26/2000 10:54:23 AM
>> To: Don_Wright/Lex/Lexmark at LEXMARK> cc: ipp%pwg.org at i...,
> pmoore%peerless.com at 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 at l...> Sent by: owner-ipp at p...> 07/26/2000 05:01 AM
>>> To: Harry Lewis/Boulder/IBM at IBMUS> cc: pmoore at p..., ipp at 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 at 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 at i... on 07/26/2000 01:00:41 AM
>> To: pmoore%peerless.com at i...> cc: ipp%pwg.org at 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 at p...> Sent by: owner-ipp at p...> 07/20/2000 09:31 AM
>>> To: ipp at 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)