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:
>> 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.
> 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...