[IPP] Required real-time clock prevents System Service use by someprinters

[IPP] Required real-time clock prevents System Service use by someprinters

Ira McDonald blueroofmusic at gmail.com
Sun Oct 2 17:02:31 UTC 2016


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


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: blueroofmusic at gmail.com
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434


On Sun, Oct 2, 2016 at 12:20 PM, <wamwagner at comcast.net> 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 <blueroofmusic at gmail.com>
> *Sent: *Sunday, October 2, 2016 11:42 AM
> *To: *ipp at pwg.org; Ira McDonald <blueroofmusic at gmail.com>
> *Subject: *[IPP] Required real-time clock prevents System Service use by
> someprinters
>
>
>
> 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: blueroofmusic at gmail.com
> Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
> May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20161002/308f939a/attachment.html>


More information about the ipp mailing list