Yes. and a printer that can't spool would do exactly the same with
the IPP job request connection. So this is not a new behavior.
Henrik
Jay Martin <jkm@underscore.com> on 26-06-2000 16:17:39
Please respond to jkm@underscore.com
To: henrik.holst@i-data.com
cc: don@lexmark.com, ipp@pwg.org
Subject: Re: IPP> TES: Mandatory IPP notification agreement
You're assuming that the printer is (essentially) idle
when you submit your job, such that the printer immediately
starts processing your job.
But what if there are *many* jobs in front of yours such
that an hour or two would pass by before your job is started?
This can happen on quality color printers, for example.
One could easily imagine this happening at a commercial
establishment, such as Kinko's, Sir Speedy, etc.
...jay
henrik.holst@i-data.com wrote:
>
> Well I'm not so sure that these kind of notification will stay with a
> connection for hours.
> If I was going to submit a job to you I would only like to get
notification
> on my job. When
> the job was completed the notifcation channel could be closed.
> What you are talking about, Don, is when I would like to monitoring your
> printer,
> but it's normal only the operator/administrator and I'm only an end user.
>
> Henrik
>
> don@lexmark.com@pwg.org on 23-06-2000 14:03:56
>
> Sent by: owner-ipp@pwg.org
>
> To: henrik.holst@i-data.com
> cc: Peter.Zehler@usa.xerox.com, ipp@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@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
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 10:53:01 EDT