Hi Mike,
If the Printer has no battery-maintained clock and doesn't have something like NTP configured to allow it to determine the time once it has powered up, it isn't clear to me how the Printer will set the value of "date-time-at-creation" to something other than 'no-value'. Does it just set it to the epoch? I had thought perhaps the Client might be always sending the "Date" HTTP Header field and the Client might set its clock that way, but I see many clients that don't include that header field in their requests.
RFC 2911 section 4.4.30 (https://tools.ietf.org/html/rfc2911#section-4.4.30 <https://tools.ietf.org/html/rfc2911#section-4.4.30>) says this:
4.4.30 printer-current-time (dateTime)
This Printer attribute indicates the current date and time. This
value is used to populate the Event Time Job Description attributes:
"date-time-at-creation", "date-time-at-processing", and "date-time-
at-completed" (see Section 4.3.14).
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, 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.
RFC 2911bis (https://tools.ietf.org/html/draft-sweet-rfc2911bis-11#section-5.4.30 <https://tools.ietf.org/html/draft-sweet-rfc2911bis-11#section-5.4.30>) didn't change this very much:
5.4.30 <https://tools.ietf.org/html/draft-sweet-rfc2911bis-11#section-5.4.30>. printer-current-time (dateTime)
This RECOMMENDED Printer attribute indicates the current date and
time. This value is used to populate the Event Time Job Status
attributes: "date-time-at-creation", "date-time-at-processing", and
"date-time-at-completed" (see Section 5.3.14 <https://tools.ietf.org/html/draft-sweet-rfc2911bis-11#section-5.3.14>).
The date and time is obtained on a "best efforts basis" and in
practice does not have to be precise in order to be useful. 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 Adminstrator. See [RFC3196 <https://tools.ietf.org/html/rfc3196>] and
[PWG5100.19 <https://tools.ietf.org/html/draft-sweet-rfc2911bis-11#ref-PWG5100.19>] for examples. If an implementation supports this
attribute and the implementation knows that it has not yet been set,
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 5.1 <https://tools.ietf.org/html/draft-sweet-rfc2911bis-11#section-5.1>.
If the DHCP leases don't contain an NTP field (option 42, if I'm not mistaken) then this puts a setup burden on the printers that would most likely not have a persistent battery supported clock.
Smith
/**
Smith Kennedy
Wireless Architect - Client Software - IPG-PPS
Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
Chair, IEEE ISTO Printer Working Group
HP Inc.
*/
> On 2016-10-02, at 4:49 AM, Michael Sweet <msweet at apple.com> wrote:
>> Smith,
>> The date-time-at-creation attribute doesn't have a no-value in the syntax because the value is set at creation of the job - it will always have a value. The -at-processing value is set when the job enters the processing state and the -at-completed value is set when the job enters a terminating state.
>> I'll need to research why we changed printer-current-time to allow no-value - it shouldn't. Either the printer supports printer-current-time or not. If the current time is unknown (waiting to get network time or have the date/time set through other mean) the value should be the unknown out-of-band value.
>> Sent from my iPad
>> On Oct 2, 2016, at 1:30 AM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>>> Greetings,
>>>> While running the IPP Everywhere Self Certification suite against a printer that has no persistent clock, we saw several failures having to do with the state of some time related attributes. When I started digging into those attributes, I discovered that some attributes, such as "date-time-at-processing" or "date-time-at-completed", are defined as (dateTime | no-value) while others such as "date-time-at-creation" or "printer-current-time" are simply defined to be of type "dateTime". And yet the description of "printer-current-time" in even the latest draft of RFC 2911bis allowed the attribute to have the out-of-band value 'no-value'.
>>>> What is the right thing to do in these cases? And should it be acceptable if a Printer that lacks a clock reports 'no-value' for "printer-config-change-date-time"? If it is OK to return 'no-value' then I think tests I-9 and I-14 may need to be fixed.
>>>> Thoughts?
>>>> Smith
>>>> /**
>> Smith Kennedy
>> Wireless Architect - Client Software - IPG-PPS
>> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
>> Chair, IEEE ISTO Printer Working Group
>> HP Inc.
>> */
>>>>>>>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20161002/93f29e54/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4956 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20161002/93f29e54/attachment.p7s>