attachment
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Mike,<br class=""><br class="">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.<br class=""><br class="">RFC 2911 section 4.4.30 (<a href="https://tools.ietf.org/html/rfc2911#section-4.4.30" class="">https://tools.ietf.org/html/rfc2911#section-4.4.30</a>) says this:<br class=""><br class=""><div class=""><font face="Courier" size="2" class="">4.4.30 printer-current-time (dateTime)</font></div><font face="Courier" size="2" class=""><br class="Apple-interchange-newline"></font><div class=""><font face="Courier" size="2" class=""> This Printer attribute indicates the current date and time. This</font></div><div class=""><font face="Courier" size="2" class=""> value is used to populate the Event Time Job Description attributes:</font></div><div class=""><font face="Courier" size="2" class=""> "date-time-at-creation", "date-time-at-processing", and "date-time-</font></div><div class=""><font face="Courier" size="2" class=""> at-completed" (see Section 4.3.14).</font></div><font face="Courier" size="2" class=""><br class="Apple-interchange-newline"></font><div class=""><font face="Courier" size="2" class=""> The date and time is obtained on a "best efforts basis" and does not</font></div><div class=""><font face="Courier" size="2" class=""> have to be that precise in order to work in practice. A Printer</font></div><div class=""><font face="Courier" size="2" class=""> implementation sets the value of this attribute by obtaining the date</font></div><div class=""><font face="Courier" size="2" class=""> and time via some implementation-dependent means, such as getting the</font></div><div class=""><font face="Courier" size="2" class=""> value from a network time server, initialization at time of</font></div><div class=""><font face="Courier" size="2" class=""> manufacture, or setting by an administrator. See [IPP-IIG] for</font></div><div class=""><font face="Courier" size="2" class=""> examples. <font color="#ff2600" class="">If an implementation supports this attribute and the</font></font></div><div class=""><font face="Courier" color="#ff2600" size="2" class=""> implementation knows that it has not yet been set, then the</font></div><div class=""><font face="Courier" color="#ff2600" size="2" class=""> implementation MUST return the value of this attribute using the</font></div><div class=""><font face="Courier" size="2" class=""><font color="#ff2600" class=""> out-of-band ’no-value’ meaning not configured.</font> See the beginning of</font></div><div class=""><font face="Courier" size="2" class=""> section 4.1.</font></div><br class="Apple-interchange-newline"><br class="">RFC 2911bis (<a href="https://tools.ietf.org/html/draft-sweet-rfc2911bis-11#section-5.4.30" class="">https://tools.ietf.org/html/draft-sweet-rfc2911bis-11#section-5.4.30</a>) didn't change this very much:<div class=""><br class=""></div><div class=""><pre class="newpage" style="font-size: 13.333333015441895px; margin-top: 0px; margin-bottom: 0px; page-break-before: always;"><span class="h4" style="line-height: 0pt; display: inline; font-size: 1em; font-weight: bold;"><h4 style="line-height: 0pt; display: inline; font-size: 1em;" class=""><a class="selflink" name="section-5.4.30" href="https://tools.ietf.org/html/draft-sweet-rfc2911bis-11#section-5.4.30" style="color: black; text-decoration: none;">5.4.30</a>. printer-current-time (dateTime)</h4></span>
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 <a href="https://tools.ietf.org/html/draft-sweet-rfc2911bis-11#section-5.3.14" class="">Section 5.3.14</a>).
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 [<a href="https://tools.ietf.org/html/rfc3196" title=""Internet Printing Protocol/1.1: Implementor's Guide"" class="">RFC3196</a>] and
[<a href="https://tools.ietf.org/html/draft-sweet-rfc2911bis-11#ref-PWG5100.19" class="">PWG5100.19</a>] for examples. <font color="#ff2600" class="">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.</font> See the beginning
of <a href="https://tools.ietf.org/html/draft-sweet-rfc2911bis-11#section-5.1" class="">Section 5.1</a>.</pre><div class=""><br class=""></div>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.<br class=""><br class=""><div class="">Smith<br class=""><br class="">/**<br class=""> Smith Kennedy<br class=""> Wireless Architect - Client Software - IPG-PPS<br class=""> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF<br class=""> Chair, IEEE ISTO Printer Working Group<br class=""> HP Inc.<br class="">*/<br class=""><br class=""><br class=""></div><br class=""><blockquote type="cite" class="">On 2016-10-02, at 4:49 AM, Michael Sweet <<a href="mailto:msweet@apple.com" class="">msweet@apple.com</a>> wrote:<br class=""><br class="">Smith,<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">Sent from my iPad<br class=""><br class="">On Oct 2, 2016, at 1:30 AM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com" class="">smith.kennedy@hp.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Greetings,<br class=""><br class="">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'.<br class=""><br class="">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.<br class=""><br class="">Thoughts?<br class=""><br class="">Smith<br class=""><br class="">/**<br class=""> Smith Kennedy<br class=""> Wireless Architect - Client Software - IPG-PPS<br class=""> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF<br class=""> Chair, IEEE ISTO Printer Working Group<br class=""> HP Inc.<br class="">*/<br class=""><br class=""><br class=""><br class=""></blockquote><blockquote type="cite" class="">_______________________________________________<br class="">ipp mailing list<br class="">ipp@pwg.org<br class="">https://www.pwg.org/mailman/listinfo/ipp<br class=""></blockquote></blockquote><br class=""></div></body></html>