While IPP/1.0 did have a solution to the persistent jobs on restart, namely,
not resetting the "printer-up-time" back to 1, the group liked allowing the
job time tick values to be adjusted to be negative (or 0), so that
"printer-up-time" MUST be reset to 1 on restart. Thus it is always up time
and has the same semantics as the MIB-II sysUpTime and the Printer MIB
prtAlertTime (except for being in seconds, instead of 100ths of a second).
So we agreed that I should ask the DL whether any implementations of IPP
uses method 1 from section 4.4.27 "printer-up-time":
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.
We are proposing to delete implementation method 1 from IPP/1.1 and adding
that the job time values can be negative to indicate a time before the
printer was most recently powered-up.
Here is the current proposed solution and text changes. Please send any
comments to the DL on this:
17) ISSUE: Client display of absolute time for job attributes?
What are clients doing with printers that don't support absolute time? How
can client display an absolute time that a job was submitted, started
processing, and completed (which is what is useful for a user)?
Possible Solution
Get Uptime from printer ("printer-up-time" - time system has been up in
seconds)
Get Job(s)
Calculate Display time = job tick time ("time-at-xxx" - in seconds that
system has been up) - uptime ("printer-up-time") + local client absolute
date and time. The down side is that the client has to get the
"printer-up-time" every time with a separate Get-Printer-Attributes
operation.
Alternatively: Add OPTIONAL job attributes: "date-time-at-creation
(dateTime)", "date-time-at-processing (dateTime)", and
"date-time-at-completion (dateTime)"
(Microsoft)
Suggested resolution:
1. Change the range on the 3 "time-at-xxx" job time attributes from 0:MAX as
it is in IPP/1.0 to MIN:MAX:
time-at-creation(integer(MIN:MAX))
time-at-processing(integer(MIN:MAX))
time-at-completed(integer(MIN:MAX))
A negative value indicates an event that happened that many seconds before
the most recent power-up of the Printer; a 0 value means that the event
occurred at some unspecified time before the printer was powered up most
recently. Describe the 0 and negative values once in the time-at-xxx
section.
2. Change the current section 4.4.26 printer-up-time(integer(1:MAX)) with
respect to restarts. Eliminate the IPP/1.0 Printer option to NOT reset the
"printer-up-time" on power-up. REQUIRE IPP/1.1 Printer's to reset the
"printer-up-time" to 1 on power-up. Then this attribute tracks the MIB-II
sysUpTime attribute and the Printer MIB prtAlertTime (except
"printer-up-time" is in seconds, instead of 100th of a second). In order to
solve the problem of time attributes for jobs that persist across the
power-up, either the implementation MUST:
(a) return "time-at-xxx" Job time attributes using the
dateTime form or
(b) reset the "time-at-xxx" Job time attributes for any
persistent jobs back to 0 to indicate that the event took place sometime
before the most recent power-up or to a negative value that represents the
number of seconds before the most recent power-up that the event took place
3. Problem: Make it easier for clients to get clock time for job events,
make it easier for clients to correlate job events with notifications which
need to use date and time (since there may not be intermediate servers to
translate relative tick time to absolute date/time), allow the Printer to
not have to adjust the time attribute values of all the persistent jobs on
power-up, avoid the need for intermediate IPP servers to translate relative
tick time as responses are cascaded back to original client.
Solution: add a dateTime attribute syntax choice to the three (now REQUIRED)
job time attributes, so that they become:
time-at-creation(integer(MIN:MAX) | dateTime)
time-at-processing(integer(MIN:MAX) | dateTime)
time-at-completed(integer(MIN:MAX) | dateTime)
Thus the value returned is either the value of the Printer's REQUIRED
"printer-up-time(integer)" or the Printer's "printer-current-time(dateTime)"
when the event occurred, depending on implementation. Now the client simply
requests these attributes and deal with which ever value it gets back.
For compatibility with IPP/1.0, indicate that an IPP/1.1 Printer MUST return
the integer value if the version number of the request is '1.0'.
Clarify that the date and time does not have to be very accurate. The time
does not have to be that precise in order to work in practice.
If an implementation cannot get the dateTime, that it MUST return the
integer value that corresponds with its REQUIRED "printer-up-time(integer)",
rather than returning the out-of-band 'no-value' value that corresponds to
its OPTIONAL "printer-current-time(dateTime)".
4. To solve the problem of the client having to make two trips to the
printer when displaying jobs:
first to get the "time-at-xxx" job attributes with Get-Jobs
or Get-Job-Attributes, and
second to get the "printer-up-time" with
Get-Printer-Attributes,
we'll add a REQUIRED job attribute:
job-printer-up-time(integer(1:MAX))
which is an alias of the Printer's "printer-up-time(integer(1:MAX))".
5. To help clients being able to depend on getting time, change the 3
"time-at-xxx(integer)" job time attributes from OPTIONAL to REQUIRED. This
shouldn't be a burden, since the corresponding printer attribute:
"printer-up-time" is already REQUIRED in IPP/1.0. Also the draft Printer
MIB and MIB-II require that a device have a clock tick capability.
6. Clarify that if an implementation supports the OPTIONAL
"printer-current-time(dateTime)" attribute by getting the time from some
source such as the network or an operator, but was unable to, that it MUST
return the out-of-band 'no-value' which means not configured (yet). See the
beginning of section 4.1 in the Model.
7. Clarify that the time zone NEED NOT be that used by people in the
vicinity of the Printer or device and that clients SHOULD convert dateTime
attributes to the time zone of the client before display to the user.
IIG: Describe some of the many ways that implementations can get the date
and time:
1. Any network printer can get time from NTP Time
server. See RFC 1305. Also DHCP option 32 in RFC 2132 returns the IP
address of the NTP server.
2. Get the date and time at startup from a human
operator
3. Have an operator set the date and time using a web
administrative interface
4. Get the date and time from incoming HTTP requests,
though the problems of spoofing need to be considered. Perhaps comparing
several HTTP requests could reduce the chances of spoofing.
5. Internal date time clock battery driven.
6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
Suggested text:
Group the three "time-at-xxx" Job Description time attributes into a single
section so that the common semantics can be said once:
4.3.12 Event Time Job Description Attributes
This section defines the Job Description attributes that indicate the time
at which certain events occur for a job. The attribute syntax MUST be
either integer or dateTime for an IPP/1.1 response, but MUST be an integer
for an IPP/1.0 response, for compatibility with IPP/1.0 [RFC 2566].
In order to populate these Event Time Job Description Attributes, the
Printer object copies either:
1. the value in its "printer-current-time" attribute
for the 'dateTime' value at the time the event occurred if the printer
supports the attribute "printer-current-time" and its value is not the
out-of-band 'no-value' value,
2. the value in its "printer-up-time" attribute for the
'integer' value at the time the event occurred otherwise
Note: because the time MAY become known to the Printer some time after
power-up, a client could receive jobs that contain some Event Time Job
Description Attributes that use the 'integer' time tick representation while
the later events use the 'dateTime' date/time representation.
If the Printer implementation keeps jobs persistently across power cycles,
then an implementation MUST reset its "printer-up-time" attribute to 1 on
each power-up. In addition, an implementation that uses the 'integer' form
MUST change all of its Event Time Job Description attributes for those
persistent jobs either:
1. to 0 to indicate that the event happened before the
most recent power up
2. to the negative of the number of seconds before the
most recent power-up that the event took place, though the negative number
NEED NOT reflect the exact number of seconds
An implementation that uses the 'dateTime' form does not change the values
of any of its Event Time Job Description Attributes for persistent jobs on
power-up.
4.3.12.1 time-at-creation (integer(MIN:MAX))
This REQUIRED attribute indicates the time at which the Job object was
created.
4.3.12.2 time-at-processing (integer(MIN:MAX))
This REQUIRED attribute indicates the time at which the Job object began
processing. The out-of-band 'no-value' value is returned if the job has not
yet been in the 'processing' state (see the beginning of Section 4.1).
4.3.12.3 time-at-completed (integer(MIN:MAX))
This REQUIRED attribute indicates the time at which the Job object completed
(or was cancelled or aborted). The out-of-band 'no-value' value is returned
if the job has not yet completed, been canceled, or aborted (see the
beginning of Section 4.1).
4.3.12.4 job-printer-up-time(integer(1:MAX))
This REQUIRED Job Description attribute indicates the amount of time (in
seconds) that the Printer implementation has been up and running. This
attribute is an alias for the "printer-up-time" Printer Description
attribute (see Section 4.4.27).
Note: A client MAY request this attribute in a Get-Job-Attributes or
Get-Jobs request and use the value returned in combination with other
requested Event Time Job Description Attributes in order to display time
attributes to a user. The difference between this attribute and the integer
value of a "time-at-xxx" attribute is the number of seconds ago that the
"time-at-xxx" event occurred. A client can compute the wall-clock time at
which the "time-at-xxx" event occurred by subtracting this difference from
the client's wall-clock time.
Suggested text for section 4.4.27 printer-current-time
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.). (so the time is 1 too high?) 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.
Suggested text for section 4.4.28 printer-current-time:
4.4.28 printer-current-time (dateTime)
This Printer attribute indicates the current wall-clock time. This value or
the value of "printer-uptime-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).
The date and time is obtained on a "best efforts basis" and does not have to
be that precise in order to work in practice. A Printer implementation sets
the value of this attribute by obtaining the date and time via some
implementation-dependent means, such as getting the value from a network
time server, initialization at time of manufacture, or setting by an
administrator. See [ipp-iig] for examples. If an implementation supports
this attribute and the implementation knows that it has not yet been set to
a correct value, then the implementation MUST return the value of this
attribute using the out-of-band 'no-value' meaning not configured. See the
beginning of section 4.1.
The time zone of this attribute NEED NOT be the time zone used by people
located near the Printer object or device. The client MUST NOT expect that
the time zone of any received date-time value to be in the time zone of the
client or in the time zone of the people located near the printer.