>> RE: IPP> TES: Mandatory IPP notification agreement
>>>> From: don at lexmark.com>> Date: Fri Jun 23 2000 - 08:03:56 EDT
>>>>>>>> I bet all the Firewall Admins will love all those persistant connections (hours
>> long?) through their firewalls.
>I doubt they'd even notice them among all the AOL IM, MSN Messenger, Yahoo Buddy, etc. connections
lasting all day long, every day.
-Carl
>> **********************************************
>> * 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) *
>> **********************************************
>>>> henrik.holst%i-data.com at interlock.lexmark.com on 06/23/2000 07:48:13 AM
>>>> To: Peter.Zehler%usa.xerox.com at interlock.lexmark.com>> cc: ipp%pwg.org at interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
>> Subject: RE: IPP> TES: Mandatory IPP notification agreement
>>>> Maybe it would help a lot if we had a method which use HTTP as transport,
>> but the
>> client did the connection to the server and the server could send
>> notification event
>> on this connection. The client don't poll the server, but gets asynchronous
>> events
>> from the server.
>> This would of course only work if the notification subscriber and
>> the notification recipient is the same.
>>>> Any comments?
>>>> Henrik
>>>> "Zehler, Peter" <Peter.Zehler at usa.xerox.com>@pwg.org on 23-06-2000 13:16:15
>>>> Sent by: owner-ipp at pwg.org>>>> To: henrik.holst at i-data.com, ipp at pwg.org>> cc:
>>>> Subject: RE: IPP> TES: Mandatory IPP notification agreement
>>>> All,
>>>> Another problem I have with a notification mechanism that uses HTTP in the
>> other direction (i.e. printer to client) is that it is difficult for the
>> print client to discover if his infrastructure will permit the
>> communication. How will the client check to see if notification is
>> possible
>> to his location on the Internet? The only ways I know are prior knowledge
>> or to poll the printer to see if you miss an event.
>>>> For this reason, and others, I am in favor of mandating email. I want to
>> finish up INDP so it may be tested at the Bake-Off along with email. INDP
>> will be useful when we really start working on QUALDOCS. I would hope that
>> "mailto://" and "indp://" would both be valid in notification
>> registrations.
>> Let the customer decide which is appropriate a given circumstance.
>>>> Pete
>>>> Peter Zehler
>> XEROX
>> Xerox Architecture Center
>> Email: Peter.Zehler at usa.xerox.com>> Voice: (716) 265-8755
>> FAX: (716) 265-8792
>> US Mail: Peter Zehler
>> Xerox Corp.
>> 800 Phillips Rd.
>> M/S 139-05A
>> Webster NY, 14580-9701
>>>> -----Original Message-----
>> From: henrik.holst at i-data.com [mailto:henrik.holst at i-data.com]
>> Sent: Friday, June 23, 2000 4:02 AM
>> To: ipp at pwg.org>> Subject: Re: IPP> TES: Mandatory IPP notification agreement
>>>> I just think it's really strange if we describe an Internet Printing
>> Protocol but the
>> mandatory notification method won't work in 99% of the user cases!
>>>> Henrik
>>>>don at lexmark.com@pwg.org on 22-06-2000 22:16:34
>>>> Sent by: owner-ipp at pwg.org>>>> To: kugler at us.ibm.com>> cc: ipp at pwg.org>>>> 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
>>>>>>http://www.pwg.org/hypermail/ipp/3693.html