At the IPP telecon yesterday, we has a good discussion with quite a few
participants and came up with the following proposal. I think that this
proposal does meet the concerns of the comments on the mailing list about
topic 17. We solicit comments on this proposal while we write up the exact
text.
Proposed resolution:
1. Keep the current section 4.4.26 printer-up-time(integer(1:MAX)) as it is
in IPP/1.0 with respect to restarts. Either the implementation:
(a) knows that it was restarted and so the value on the restart is
greater than it was in the printer's former life or
(b) the Printer sets the printer-up-time to 1 and resets the time
attributes for any persistent jobs back to 0.
2. Keep the range on the 3 job time attributes as 0:MAX as it is in IPP/1.0:
time-at-creation(integer(0:MAX))
time-at-processing(integer(0:MAX))
time-at-completed(integer(0:MAX))
There is no need for negative time; a 0 value means that the event occurred
before the printer was powered up. Add a forward reference to 4.4.26
printer-up-time about a 0 value meaning the event was before the printer was
powered up, since many readers missed the point that the restart problem was
already handled in IPP/1.0.
3. To solve the problem of the client having to make two trips to the
printer when displaying jobs, 1 to get the "time-at-xxx" job attributes, and
2 to get the "printer-up-time", we'll add a REQUIRED job attribute:
job-printer-up-time(integer(1:MAX))
which is a copy of the Printer's "printer-up-time(integer(1:MAX))".
4. 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.
5. 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.
6. To help with clients being able to get dates as well, which also helps
when printers are cascaded, add a dateTime attribute syntax choice to the
three (now REQUIRED) job time attributes, so that they become:
time-at-creation(integer(0:MAX) | dateTime)
time-at-processing(integer(0:MAX) | dateTime)
time-at-completed(integer(0: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'.
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)".
How does this proposal sound?
Thanks,
Tom