IPP> notification methods

IPP> notification methods

kugler at us.ibm.com kugler at us.ibm.com
Mon Aug 7 11:45:38 EDT 2000



POP3 and IMAP are a big help, because with them you don't need to run an
SMTP server (e.g., sendmail) on your end-user box.  Instead, mail goes to a
shared server and end-user CLIENTs pull messages from the server.

ICQ and IM do not put a TCP/IP server at the user end (I'm using the word
"server" in its classic TCP/IP sense;  see definition a few emails back).
Of course those clients receive packets, but they don't accept TCP/IP
connections.  In fact, IM is a good illustration that a protocol based on
long-lasting connections can scale.  These connections are initiated from
the end-user client, and last as long as the user is "present" on IM.

And the problem isn't just with firewalls.  There are other reasons that
make it impractical to put a TCP/IP server at the user end, on the
Internet.  Intranet, okay.

     -Carl



don at lexmark.com on 08/07/2000 04:13:03 AM

To:   Carl Kugler/Boulder/IBM at IBMUS
cc:   ipp at pwg.org
Subject:  Re: IPP> notification methods



...and every day we hear about another virus arriving via e-mail that
causes the
user hard disk to be formatted.   So POP3 and IMAP aren't any help.

My ISP has never complained because I run ICQ or Instant messager... these
applications act as a "server" in your overly broad definition of a server
because they receive a packet of data from another computer.  Any IM
protocol
will have to do that.

This discussion is going nowhere.  One of the primary premises is that IETF
protocols are supposed to be designed for the end-to-end  continuity case
and
that is what we are doing.  Grossly defunctioning a protocol because of
Firewalls is clearly not consistant with the IETF's goals so let's get on
with
it.

>From my perspective, this is the END OF DISCUSSION.

**********************************************
* 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 05:34:56 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





Ever heard of POP3 and/or IMAP?  Necessity is the mother of invention;
these protocols were invented to solve just this problem.  (Not to mention
Lotus Notes, Microsoft Exchange, and other proprietary solutions.)  I doubt
port 25 on "lexmark.com" is a sendmail daemon running on your desktop box!

     -Carl




don at lexmark.com on 08/04/2000 03:12:06 PM

To:   Carl Kugler/Boulder/IBM at IBMUS
cc:   ipp at pwg.org
Subject:  Re: IPP> notification methods



What about mail servers?  Just 1 example.

**********************************************
* 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 05:10:40 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





No, indp is impractical on the Internet because it puts the server at the
user's end.  There is no protocol in wide use on the Internet today that
does this.  Consequently, the infrastructure doesn't support it.  So,
there's more to it than configuring a firewall.

     -Carl




don at lexmark.com on 08/04/2000 02:46:38 PM

To:   Carl Kugler/Boulder/IBM at IBMUS
cc:   ipp at pwg.org
Subject:  Re: IPP> notification methods



Given a firewall not configured "properly", all Internet Protocols are
therefore
impractical... given your definition.

**********************************************
* 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 04:40:03 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





Me and 99% of other end users in the real world.  INDP over the Internet is
not impossible, just impractical.

     -Carl


don at lexmark.com on 08/04/2000 02:16:05 PM

To:   Carl Kugler/Boulder/IBM at IBMUS
cc:   ipp at pwg.org
Subject:  Re: IPP> notification methods

Then it sounds like YOU will have to live with e-mail while others can
enjoy
INDP.

**********************************************
* 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 04:14:07 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





Our firewall admins insist on more than hope.  One bad (broken,
misconfigured, back-doored, ...) INDP server, of possibly thousands in the
enterprise, would be enough to lay open the whole corporate network if the
firewall were to allow inbound connections.  INDP inbound through the
firewall would never fly here, that's for sure.

There are other virtually insurmoutable problems.  Most Internet client
hosts are simply not addressable as servers (because of network-address
translation, proxies, SOCKS, dynamically-assigned addresses (e.g., DHCP or
dial-up), etc).  There probably wouldn't be enough Internet addresses to go
around if they were.

     -Carl



don at lexmark.com on 08/04/2000 01:21:50 PM

To:   Carl Kugler/Boulder/IBM at IBMUS
cc:   Private_User at lexmark.com, ipp at pwg.org
Subject:  Re: IPP> notification methods



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)















































More information about the Ipp mailing list