Subject: [IPP] Required real-time clock prevents System Service use by some printers

From: Ira McDonald <[email-masked]>
Date: Sun, 2 Oct 2016 11:41:52 -0400

Hi,

The System Service requirement for a running tick counter and
for an actual RTC w/ meaningful time would prevent the use of any
Resource operations by some printers.  Also, the firmware update
and graceful restart abilities, which move away from traditional
vendor- and model-specific approaches and improve Managed
Print Service compatibility.

Questions:

(1) Should we reduce the various "date-time-at-xxx" attributes to
RECOMMENDED?
-- Comment - they are REQUIRED in IPP Everywhere

(2) Should we allow the various "time-at-xxx" attributes to be
trivial implementations (i.e., without meaningful tick counter)?
-- Comment - they are REQUIRED in RFC2911/RFC2911bis,
with some ambiguity about implementation

Note that I've personally been a proponent of required RTC
with meaningful date/time for years, so I'm conflicted about
bringing this subject up.

WDYT?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434
_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: <[email-masked]>
Date: Sun, 2 Oct 2016 12:20:03 -0400

I am surprised to see the RTC (a term I have disliked since it means something else at the detailed hardware level) or NTP question come up again. This was an issue with the printer MIB 15 years ago, but since even the most minor device seems to have time keeping capabilities today, I did think it was an non-issue. Smith’s message suggests this may be wrong. But I suggest that any imaging system complex enough to concern itself with system functions will have timekeeping capability. Unless someone can come up with a real and valid example of a networked imaging device for which system service capability is appropriate that does not have timekeeping capability, I suggest that these time related attributes remain required.
Thanks,
Bill Wagner

From: Ira McDonald
Sent: Sunday, October 2, 2016 11:42 AM
To: [email-masked]; Ira McDonald
Subject: [IPP] Required real-time clock prevents System Service use by someprinters

Hi,

---

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

Bill,

> On Oct 2, 2016, at 12:20 PM, [email-masked] wrote:
> 

The main issue is entry-level printers that lack a battery-backed real-time clock, so you need to set the date-time once after each power cycle.  Many consumer inkjet printers ask the user to enter the date and time when you power them up, others will try to get the time from the network or Client request.

> May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: Ira McDonald <[email-masked]>
Date: Sun, 2 Oct 2016 13:02:31 -0400

Hi Bill,

Thanks for that reasoned response.  I agree with you.

Sorry for probably having abused "RTC".  I didn't mean necessarily
the discrete chip w/ battery.  Useful network Printers (i.e., accessible
via some network path, wired or wireless), can maintain a running tick
counter aligned with some network notion of localized time easily.

Mike also just articulated the constraints better than I did.  Read on.

I'd like to see consumer, modest printers able to use and discover
all installed Resources with System Service.

Cheers,
- Ira

On Sun, Oct 2, 2016 at 12:20 PM, <[email-masked]> wrote:

> I am surprised to see the RTC (a term I have disliked since it means
> something else at the detailed hardware level) or NTP question come up
> again. This was an issue with the printer MIB 15 years ago, but since even
> the most minor device seems to have time keeping capabilities today, I did
> think it was an non-issue. Smith’s message suggests this may be wrong. But
> I suggest that any imaging system complex enough to concern itself with
> system functions will have timekeeping capability. Unless someone can come
> up with a real and valid example of a networked imaging device for which
> system service capability is appropriate that does not have timekeeping
> capability, I suggest that these time related attributes remain required.
>
> Thanks,
>
> Bill Wagner
>
>
>
>
>
>
>
> *From: *Ira McDonald <[email-masked]>
> *Sent: *Sunday, October 2, 2016 11:42 AM
> *To: [email-masked]; Ira McDonald <[email-masked]>
> *Subject: *[IPP] Required real-time clock prevents System Service use by
> someprinters
>
>
>
> Hi,
>

---

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

Ira,

> On Oct 2, 2016, at 11:41 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> Resource operations by some printers.

How exactly?

TLS basically requires the date and time to be set to generate an X.509 certificate or do validation of certificates in things like firmware updates and applications.

> Also, the firmware update

Given that we require TLS, we are requiring a real-time clock of some sort and thus we should make these REQUIRED (better for accounting).

> with some ambiguity about implementation 

These should follow the same rules as for Jobs - copy the printer-up-time/system-up-time value while running, report 0 if the time is before the service started.

> bringing this subject up.

I think that ship sailed as soon as we required TLS.  And for resource validation we need a date and time as well.

I think the only ambiguity is "how does the date and time get set", which should be talked about in security considerations since the wrong date/time can have consequences. (thus the work in the IETF for a secure version of NTP)

---

From: Ira McDonald <[email-masked]>
Date: Sun, 2 Oct 2016 13:16:52 -0400

Hi Mike,

Very good points.  TLS means the system must have a reasonable
notion of network time.  And TLS is certainly a must-have for firmware
or most other Resource-related operations.

I'd be happy to get some input on the Security Considerations section
about the importance of meaningful network time (e.g., for both session
restart and certificate validation/revocation).

I was feeling very queasy about downgrading required attributes from
IPP Everywhere, which ought to be our "floor" for printers with System
Service.  Shouldn't we require IPP Everywhere in System Service?

Cheers,
- Ira

On Sun, Oct 2, 2016 at 1:09 PM, Michael Sweet <[email-masked]> wrote:

> TLS basically requires the date and time to be set to generate an X.509
> certificate or do validation of certificates in things like firmware
> updates and applications.
>
> Given that we require TLS, we are requiring a real-time clock of some sort
> and thus we should make these REQUIRED (better for accounting).
>
> These should follow the same rules as for Jobs - copy the
> printer-up-time/system-up-time value while running, report 0 if the time is
> before the service started.
>
> I think that ship sailed as soon as we required TLS.  And for resource
> validation we need a date and time as well.
>
> I think the only ambiguity is "how does the date and time get set", which
> should be talked about in security considerations since the wrong date/time
> can have consequences. (thus the work in the IETF for a secure version of
> NTP)
>
>
> >
> > WDYT?
> >
> > Cheers,
> > - Ira
> >

---

From: Michael Sweet <[email-masked]>
Date: Sun, 02 Oct 2016 13:43:32 -0400

Ira,

> On Oct 2, 2016, at 1:16 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Mike,
> 

I wouldn't go quite that far, but definitely recommend IPP Everywhere and require IPP/2.x.