Polling is pollings. Notification is asynchronous.
Do you ask the postman everyday if you have mail and if you do you go get it?
No. The mail is brought to you whether you know it is coming or not. ANYTHING
that requires the client to actively pursue getting the state of the print job
is POLLING.
**********************************************
* 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 06/23/2000 11:41:16 AM
To: Don_Wright/Lex/Lexmark at LEXMARK
cc: henrik.holst%i-data.com at interlock.lexmark.com,
ipp%pwg.org at interlock.lexmark.com,
Peter.Zehler%usa.xerox.com at interlock.lexmark.com (bcc: Don
Wright/Lex/Lexmark)
Subject: RE: IPP> TES: Mandatory IPP notification agreement
NO!
What Henrik describes was contained in my high-level proposal which
combined synchronous, "server directed polling" with a final, "print
eminent" persistent connection flowing asynchronous events.
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/Simple_IPP_Notification.pdf
This proposal addressed the issue of long persistent connections but kept
the protocol "native" (using HTTP from client to IPP printer). The main
criticism was the potential for a proxy to cache (bundle) events that
flowed during the asynchronous period. Not sure why this concern was
viewed any greater than the firewall issues plaguing other methods.
I'm not "against" INDP or Mail. I think they both have great merit. I do
feel we have fallen short of describing and prescribing a simple, native
(utilizing existing IPP infrastructure), mandatory (read interoperable)
notification method. If we don't think lack thereof will create interop
issues... just reflect on the difficulty we're having to determine how to
conduct a successful notification bakeoff!
Harry Lewis
IBM Printing Systems
don at lexmark.com
Sent by: owner-ipp at pwg.org
06/23/2000 06:03 AM
To: henrik.holst at i-data.com
cc: Peter.Zehler at usa.xerox.com, ipp at pwg.org
Subject: RE: IPP> TES: Mandatory IPP notification agreement
I bet all the Firewall Admins will love all those persistant connections
(hours
long?) through their firewalls.
**********************************************
* 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