IPP Mail Archive: RE: IPP> Proposal for change to notification content [add job-imp

IPP Mail Archive: RE: IPP> Proposal for change to notification content [add job-imp

RE: IPP> Proposal for change to notification content [add job-imp

Hastings, Tom N (hastings@cp10.es.xerox.com)
Thu, 21 Oct 1999 12:33:55 -0700


I will add as an issue for the upcoming meeting and we will process it. It
does make sense to send them if you support them, so you can get a real

Don't you need to know the job-collation-type in order to know whether the
counter is going to go to n times the size or just to the size, where n is
the number of copies?

So do we need to add "job-collation-type" as well?


-----Original Message-----
From: dcarney@us.ibm.com [mailto:dcarney@us.ibm.com]
Sent: Thursday, October 21, 1999 08:33
To: hastings@cp10.es.xerox.com
Subject: IPP> Proposal for change to notification content


Could you please add this proposal to the issue list for the notification
document? Thanks.

Let me know if you have any questions.

---------------------- Forwarded by Dennis Carney/Boulder/IBM on 10/21/99
AM ---------------------------

dcarney@us.ibm.com on 10/06/99 08:28:28 PM

To: ipp@pwg.org
Subject: IPP> Proposal for change to notification content

Here is the proposal that was promised at the September PWG meeting in

(I'm not sure which version of the Notification spec I should be using, so
use the one that looks the most recent to me:

I am proposing adding three new rows to table 5 in section "7.3 Additional
Notification content attributes for Job event only". This is being done so
that a monitoring application can present a "gas gauge" showing progress of
job. To show a gas gauge, the application needs to know *both* the "total"
our case, for example, the total number of impressions that will print for
job) and the "progress" (the number of impressions printed so far)
Showing such a gas gauge is not possible using the current notification
unless the monitoring application were to query (poll) for the "total"

Specifically, the three new rows that would be added:
26. job-k-octets (integer (0:MAX)) mod O O
27. job-impressions (integer (0:MAX)) mod CR CR
28. job-media-sheets (integer (0:MAX)) mod CR CR

These attributes are the "total" values corresponding to the "progress"
stored in the three attributes shown in rows 18, 19, and 20 of table 5
(job-k-octets-processed, job-impressions-completed,

As far as I can see, the main objection to this proposal comes from people
say "But the number of impressions that are going to print doesn't change as
job progresses, so why should we pass the same old information on every
notification?" My answer: au contraire--the values *do* change! As
in the model document, the printer may set these values when it knows them.
That is, when the printer determines the number of impressions that are
going to
print, it will set the job-impressions attribute. That might happen before
first page prints (contrary to some people's belief, I see this all the
even on 20+ page jobs (but not on pdf jobs :-) ), it might happen 5 pages
in, 15
pages in, or 2 pages before the last page prints. In any case, the
application can not know ahead of time when this information will be
so if it really wants to present a gas gauge, it has to wait for
for "progress" values, but *constantly poll* for "total" values! If it's
polling for the "total" values, it might decide to just grab the "progress"
values while it's at it and forget about notifications altogether.

Note that these values need to be passed on 'job-completed' notifications as
well, because the monitoring application would like to know how far the job
For example, if the job was canceled, it is useful to know that 22 of 24
printed as opposed to 22 of 444 pages. Also, on printers that do not set
"total" value when they know it, there is no guarantee that the "total"
matches the "progress" value even on jobs that completed, and this might be
interest to a monitoring application: if it sees a job that was thought by
sender to be a 14 page job but 47 pages printed, it might want to throw up
sort of warning that the job might not have printed correctly. Note also
there is only one 'job-completed' notification per job, so passing more
information than might be necessary in some cases is not too costly (these
values are all simple integers in any case, so they take up little room).
Remember that some notification recipients might request 'job-completed'
notifications and not 'job-progress' notifications.

Comments, counter-proposals, questions anyone?

Dennis Carney
IBM Printing Systems (303)924-0565