[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?

Kennedy, Smith (Wireless Architect) smith.kennedy at hp.com
Sun Oct 2 13:03:06 UTC 2016


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>


More information about the ipp mailing list