IPP Mail Archive: IPP> MOD - part of Issue 17 - don't need negative "time-at-xxx" Job At

IPP> MOD - part of Issue 17 - don't need negative "time-at-xxx" Job At

Hastings, Tom N (hastings@cp10.es.xerox.com)
Mon, 26 Apr 1999 15:52:24 -0700

While writing up the part of Issue 17 about clarifying that the time-at-xxx
Job attributes MAY be negative after a restart for systems that keep jobs
persistently, I discovered that the "printer-up-time" Printer Description
attribute has already dealt with the problem of restarts in a different way.
The value of the "time-at-xxx" is reset to 0 and stays there for each
persistently held job on a restart. The following text is in the June 1998
Model. I added the last sentence to clarify that an implementation could
use both methods depending on the type of restart.

So ok NOT to change the "time-at-xxx" Job attributes from "time-at-xxx"
(integer(0:MAX)) to "time-at-xxx" (integer(MIN:MAX))? To help, I'll add a
reference to each of the "time-at-xxx" attributes to the "printer-up-time"
attribute, so that implementer's will see the restart explanation.

4.4.26 printer-up-time (integer(1:MAX))
This REQUIRED Printer attribute indicates the amount of time (in seconds)
that this instance of this Printer implementation has been up and running.
This value is used to populate the Job attributes "time-at-creation",
"time-at-processing", and "time-at-completed". These time values are all
measured in seconds and all have meaning only relative to this attribute,
"printer-up-time". The value is a monotonically increasing value starting
from 1 when the Printer object is started-up (initialized, booted, etc.).
If the Printer object goes down at some value 'n', and comes back up, the
implementation MAY:
1. Know how long it has been down, and resume at some value greater
than 'n', or
2. Restart from 1.

In the first case, the Printer SHOULD not tweak any existing related Job
attributes ("time-at-creation", "time-at-processing", and
"time-at-completed"). In the second case, the Printer object SHOULD reset
those attributes to 0. If a client queries a time-related Job attribute and
finds the value to be 0, the client MUST assume that the Job was submitted
in some life other than the Printer's current life. An implementation MAY
use both cases, depending on warm versus cold start, respectively.

I've also added the two last paragraphs to "printer-current-time", the first
relating to the 3 new "date-time-at-xxx (dateTime)" Job Description
attributes that Issue 17 is adding, and the second to clarify that the time
zone need not be that of the device. Ok?
4.4.27 printer-current-time (dateTime)
This Printer attribute indicates the current absolute wall-clock time. If
an implementation supports this attribute, then a client could calculate the
absolute wall-clock time for each Job's "time-at-creation",
"time-at-processing", and "time-at-completed" attributes by using both
"printer-up-time" and this attribute, "printer-current-time". If an
implementation does not support this attribute, a client can only calculate
the relative time of certain events based on the REQUIRED "printer-up-time"
attribute.
If an implementation supports this attribute, then this value is used to
populate the Job attributes "date-time-at-creation",
"date-time-at-processing", and/or "date-time-at-completed" Job attributes.
ISSUE 17
The time zone in this value NEED NOT be the time zone of the Printer object
or device. Therefore, the vendor MAY ship the implementation using GMT, for
example, with no way to change the time zone. The client SHOULD display any
dateTime attributes using the time zone of the client.