attachment
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;">Smith,</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">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.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">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.</div><br>Sent from my iPad</div><div><br>On Oct 2, 2016, at 1:30 AM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com">smith.kennedy@hp.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Greetings,</span><br><span></span><br><span>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'.</span><br><span></span><br><span>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.</span><br><span></span><br><span>Thoughts?</span><br><span></span><br><span>Smith</span><br><span></span><br><span>/**</span><br><span> Smith Kennedy</span><br><span> Wireless Architect - Client Software - IPG-PPS</span><br><span> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF</span><br><span> Chair, IEEE ISTO Printer Working Group</span><br><span> HP Inc.</span><br><span>*/</span><br><span></span><br><span></span><br><span></span><br></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>ipp mailing list</span><br><span><a href="mailto:ipp@pwg.org">ipp@pwg.org</a></span><br><span><a href="https://www.pwg.org/mailman/listinfo/ipp">https://www.pwg.org/mailman/listinfo/ipp</a></span><br></div></blockquote></body></html>