>> RE: IPP> TES: Mandatory IPP notification agreement
>>
>> From: don@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@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@interlock.lexmark.com on 06/23/2000 07:48:13 AM
>>
>> To: Peter.Zehler%usa.xerox.com@interlock.lexmark.com
>> cc: ipp%pwg.org@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@usa.xerox.com>@pwg.org on 23-06-2000 13:16:15
>>
>> Sent by: owner-ipp@pwg.org
>>
>> To: henrik.holst@i-data.com, ipp@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@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@i-data.com [mailto:henrik.holst@i-data.com]
>> Sent: Friday, June 23, 2000 4:02 AM
>> To: ipp@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@lexmark.com@pwg.org on 22-06-2000 22:16:34
>>
>> Sent by: owner-ipp@pwg.org
>>
>> To: kugler@us.ibm.com
>> cc: ipp@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@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@interlock.lexmark.com on 06/22/2000 04:13:36 PM
>>
>> To: Don_Wright/Lex/Lexmark@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@lexmark.com on 06/22/2000 01:40:16 PM
>>
>> To: Carl Kugler/Boulder/IBM@IBMUS
>> cc:
>> Subject: Re: IPP> TES: Mandatory IPP notification agreement
>>
>> Firewalls are configurable.
>>
>> Don
>>
>> kugler%us.ibm.com@interlock.lexmark.com on 06/22/2000 03:33:16 PM
>>
>> To: Don_Wright/Lex/Lexmark@LEXMARK
>> cc: ipp%pwg.org@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@lexmark.com on 06/22/2000 12:04:27 PM
>>
>> To: Carl Kugler/Boulder/IBM@IBMUS
>> cc: ipp@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@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@interlock.lexmark.com on 06/21/2000 06:08:52 PM
>>
>> To: ipp%pwg.org@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@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@pwg.org
>> cc:
>> From: Carl Kugler/Boulder/IBM@IBMUS
>> Subject:
>>
>> "Zehler, Peter" <Peter.Zehler@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@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
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 18:08:59 EDT