[IPP] Why are some attributes that provide a dateTime data type allowed to specify "no-value" while others are not?

[IPP] Why are some attributes that provide a dateTime data type allowed to specify "no-value" while others are not?

[IPP] Why are some attributes that provide a dateTime data type allowed to specify "no-value" while others are not?

Michael Sweet msweet at apple.com
Sun Oct 2 10:49:09 UTC 2016


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/55783a03/attachment.html>


More information about the ipp mailing list