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

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Sun, 2 Oct 2016 05:30:40 +0000

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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Sun, 02 Oct 2016 06:49:09 -0400

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) <[email-masked]> wrote:
> 
> Greetings,
>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Sun, 2 Oct 2016 13:03:06 +0000

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

> On 2016-10-02, at 4:49 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
>

---

From: Michael Sweet <[email-masked]>
Date: Sun, 02 Oct 2016 12:48:57 -0400

Smith,

> On Oct 2, 2016, at 9:03 AM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> 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'.

Probably the best thing is to omit the attribute if the RTC is not configured when the job is created, or not accept new jobs until the clock is set...  But a strict interpretation of the spec would have the Printer copying the 'no-value' from "printer-current-time" to the "date-time-at-creation" attribute.

> RFC 2911 section 4.4.30 (https://tools.ietf.org/html/rfc2911#section-4.4.30) says this:
> 

RFC 2566 (IPP/1.0) did not have the second paragraph...  Under our current guidance for 'no-value' and 'unknown' usage, this attribute SHOULD report 'unknown' when the date and time is not yet configured since, like "printer-geo-location", there is always a current date and time - the value is merely unknown.

We should discuss whether to change this to 'unknown' when RFC2911bis hits AUTH48 at our Wednesday conference call.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 11 Oct 2016 05:36:34 +0000

Just replying for the sake of posterity - this was discussed in the Oct. 5 IPP WG meeting, where we decided that "printer-current-time" should be able to hold a value of "unknown". See the minutes from that meeting for details.

Smith

> On Oct 2, 2016, at 10:48 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
>