I think this still means that its ok to delete method 1 from IPP/1.1, since
you never reset the "printer-up-time" attribute and so the job time tick
("time-at-xxx") never need adjustment.
In other words, if the printer never goes down, then the "printer-up-time"
is still the time since the Printer object was started.
So the following proposed description for "printer-up-time" will not impact
your implementation, correct:
4.4.27 printer-up-time (integer(1:MAX))
This REQUIRED Printer attribute indicates the amount of time (in seconds)
that this Printer instance has been up and running. The value is a
monotonically increasing value starting from 1 when the Printer object is
started-up (initialized, booted, etc.). This
value or the value of "printer-current-time" is used to populate the Job
attributes "time-at-creation", "time-at-processing", and
"time-at-completed", depending on implementation (see Section 4.3.12).
If the Printer object ceases running and restarts, the implementation MUST
reset this value to 1.
From: Anthony Porter [mailto:anthony.porter at computer.org]
Sent: Friday, May 07, 1999 01:09
To: 'Hastings, Tom N'; 'ipp'
Subject: RE: IPP> MOD - REVISITED Issue 17 - Client display of absolute
date and time for job attributes
I implement method 1 and maintain the printer-up-time. The reason is that
the printer is not one unique component.
Method 1 is the same as method 2 if the printer never goes down.
I dont think the job-printer-up-time is necessary, since once the client has
the printer-up-time, it knows time when the printer reboot occurred and can
calculate the local times of all the jobs. The client must refresh the
printer-up-time occasionally, in case the printer has rebooted, but the
client can do this when it queries the printer for other attributes, such as
printer-state. There is of course a risk that the client might occasionally
display incorrect times if the printer reboots frequently, but maybe that is
not so important.
job-printer-up-time does not do any harm of course, but clients will have to
cope anyway with V1.0 servers that don't supply it.
A minor point is that if the client asks for a long list of jobs, the server
might take a while to prepare it, and the job-printer-up-time returned for
each job might not be the same. I guess that the client ought to take the
last job-printer-up-time in the list.