IPP> TES: Mandatory IPP notification agreement

IPP> TES: Mandatory IPP notification agreement

IPP> TES: Mandatory IPP notification agreement

Stuart Rowley Stuart.Rowley at ktd-kyocera.com
Fri Jun 23 11:38:50 EDT 2000


I think Paul's arguments make sense, and I have not seen anyone refute them.
If a company deems that the mandatory method is not at all applicable to
their "zone", as Paul calls it, then they will most likely not implement it.
Making things mandatory is intended to guarantee interoperability, but is a
mandatory notification method going to guarantee notifications will work?
No. 

Can someone state why it is essential to identify a mandatory method?

Stuart Rowley
Kyocera Technology Development

> -----Original Message-----
> From: pmoore at peerless.com [mailto:pmoore at peerless.com]
> Sent: Thursday, June 22, 2000 1:39 PM
> To: don at lexmark.com
> Cc: kugler at us.ibm.com; ipp at pwg.org
> Subject: Re: IPP> TES: Mandatory IPP notification agreement
> 
> 
> Like I said before - why do we have to mandate one or more 
> methods. THe only
> reason for mandating things is so that a client can be 
> guaranteed that a service
> will exist (I.e all IPP client can safely be built using 
> print-job because it
> MUSTbe there).
> 
> Since notifications are a) optional and b) not always going 
> to work (because of
> firewall issues, or other reasons - I might be at a site that 
> doesnt have an
> SMTP infrastructure - unlikely but possible) then a client 
> can never make that
> assumption.  A client builder must always be prepared to deal 
> with the fact that
> their favorite notification method is not available. 
> Therefore the mandating of
> methods is useless.
> 
> I think what various people are really saying is 'these are 
> the two no-brainer
> methods(mail & INDP) that we need to get standardized and 
> baked-off' - I agree
> with them.
> 
> 
> 
> 
> 
> 
> don at lexmark.com on 06/22/2000 01:16:34 PM
> 
> To:   kugler at us.ibm.com
> cc:   ipp at pwg.org (bcc: Paul Moore/AUCO/US)
> 
> Subject:  Re: IPP> TES: Mandatory IPP notification agreement
> 
> 
> 
> Just because there are cases where a machine can't get 
> notifications does not
> mean we should not standardize it.  By making it mandatory, 
> developers of
> products must support it.  It doesn't mean that everyone must 
> use it.  (BTW:  I
> am also in favor of making e-mail mandatory).
> 
> **********************************************
> * 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 06/22/2000 04:13:36 PM
> 
> To:   Don_Wright/Lex/Lexmark at LEXMARK
> cc:    (bcc: Don Wright/Lex/Lexmark)
> Subject:  Re: IPP> TES: Mandatory IPP notification agreement
> 
> 
> 
> 
> 
> Many firewalls allow you to connect many more machines to the 
> Internet than
> you have IP addresses for.  The addresses behind the firewall may be
> private, unregistered addresses,  not globally routable, not globally
> unique.
> 
>      -Carl
> 
> 
> 
> don at lexmark.com on 06/22/2000 01:40:16 PM
> 
> To:   Carl Kugler/Boulder/IBM at IBMUS
> cc:
> Subject:  Re: IPP> TES: Mandatory IPP notification agreement
> 
> 
> 
> Firewalls are configurable.
> 
> Don
> 
> 
> 
> 
> kugler%us.ibm.com at interlock.lexmark.com on 06/22/2000 03:33:16 PM
> 
> To:   Don_Wright/Lex/Lexmark at LEXMARK
> cc:   ipp%pwg.org at interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
> Subject:  Re: IPP> TES: Mandatory IPP notification agreement
> 
> 
> 
> 
> 
> Will go through OUTBOUND from a Printer INSIDE to a client 
> OUTSIDE.  But
> what if the CLIENT is behind a firewall?
> 
>      -Carl
> 
> 
> don at lexmark.com on 06/22/2000 12:04:27 PM
> 
> To:   Carl Kugler/Boulder/IBM at IBMUS
> cc:   ipp at pwg.org
> Subject:  Re: IPP> TES: Mandatory IPP notification agreement
> 
> 
> 
> In the matter of INDP and firewalls, INDP WILL go through a properly
> configured
> firewall.  It won't go through one that blocks on whatever port we are
> assigned.
> 
> Let's be accurate.
> 
> **********************************************
> * 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 06/21/2000 06:08:52 PM
> 
> To:   ipp%pwg.org at interlock.lexmark.com
> cc:    (bcc: Don Wright/Lex/Lexmark)
> Subject:  Re: IPP> TES: Mandatory IPP notification agreement
> 
> 
> 
> 
> 
> [Added subject line and this P.S.:]
> 
> henrik.holst at i... wrote:
> >
> > Well it was my understanding that we didn't agree on a 
> mandatory method.
> > And the INDP method
> > won't go through a firewall, so if you are searching for a mandatory
> method
> > I would say MAILTO.
> 
> I agree, INDP won't go through firewalls.
> 
> ---------------------- Forwarded by Carl Kugler/Boulder/IBM 
> on 06/21/2000
> 04:07 PM ---------------------------
> 
> From: Carl Kugler on 06/21/2000 03:39 PM
> 
> To:   ipp at pwg.org
> cc:
> From: Carl Kugler/Boulder/IBM at IBMUS
> Subject:
> 
> 
> "Zehler, Peter" <Peter.Zehler at u...> wrote:
> ..
> > My preference is that INDP be mandated.  I feel that programmatic
> > notification is critical to the development of robust IPP 
> applications.
> One
> > of those applications would be QUALDOCS.  In the definition 
> of IPP, and
> its
> > associated notification mechanism, I am concerned primarily 
> with client
> > /server communications.  End user notification, while 
> useful, is not my
> > primary objective.  It is true that infrastructure will have to be
> > configured to allow this traffic to pass.  The same is true 
> of outbound
> IPP
> > requests. I imagine that most of our printers will also 
> implement mailto.
> I
> > have no objections to allowing both, but I think only one should be
> > mandated.
> >
> ..
> 
> Actually, in many cases the infrastructure does not have to 
> be configured
> to allow outbound IPP requests.  I've always been able to 
> connect to IPP
> Printers on the Internet with an IPP client here inside the 
> IBM firewall.
> (In fact, I remember connecting my client to your Printer a 
> few years ago!)
> We run a SOCKS Internet gateway here, and I can make a TCP 
> connection to
> any host:port on the Internet.
> 
> "McDonald, Ira" <imcdonald at s...> wrote:
> ..
> > Lastly, Peter you jumped from port filtering by firewalls
> > to MIME type filtering - but the latter requires that the
> > firewall have an Application Layer Gateway (ALG) to figure
> > out the protocol and THEN to find the MIME type inside the
> > protocol envelope.
> >
> > Personally, I agree with Henrik about selecting email as
> > the IPP mandatory notification method.
> >
> 
> Most firewalls allow insiders to make outbound connections (perhaps
> indirectly), but prevent outsiders from making inbound 
> connections.  Very
> few corporate firewall administrators would be willing to 
> simply open a
> port and allow anybody to make inbound connections to 
> arbitrary addresses
> inside the firewall.  Here at IBM, making an inbound 
> connection requires
> full-blown authentication, encryption, one-time passwords, etc. (by
> strictly enforced corporate policy).   We use Aventail for 
> this.  Also, in
> many cases, machines inside a firewall are simply not addressable from
> outside, due to network address translation (NAT), IP 
> Masquerading, Windows
> connection sharing, etc.  You'd need a really sophisticated
> application-level gateway to deal with these issues.
> 
>      -Carl
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



More information about the Ipp mailing list