IPP> notification methods

IPP> notification methods

IPP> notification methods

Carl-Uno Manros carl at manros.com
Wed Jul 26 10:57:32 EDT 2000


Don,

I fully agree with your statement. I think we have now reached a time where
it is crusial to get the firewall people to develop product solutions that
will allow IPP traffic, and INDP traffic through firewalls. The basic
philosophy for all firewalls is to stop anything they don't understand. So
let us start serious discussions with the firewall vendors and major
organizations that use firewalls about HOW to do it, instead of assuming
that they never will do it. NO new protocol can succeed if we just stay
inactive.

Carl-Uno

> -----Original Message-----
> From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of
> don at lexmark.com
> Sent: Wednesday, July 26, 2000 4:01 AM
> To: harryl at us.ibm.com
> Cc: pmoore at peerless.com; ipp at pwg.org
> 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 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)      *
> **********************************************
>
>
>
>
>
>
> harryl%us.ibm.com at interlock.lexmark.com on 07/26/2000 01:00:41 AM
>
> To:   pmoore%peerless.com at interlock.lexmark.com
> cc:   ipp%pwg.org at interlock.lexmark.com (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 peerless.com
> Sent by: owner-ipp at pwg.org
> 07/20/2000 09:31 AM
>
>
>         To:     ipp at pwg.org
>         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