An implementation MAY support this attribute by obtaining the date and time
by any number of implementation-dependent means at startup or subsequently.
See [ipp-iig] for examples. If an implementation supports this attribute by
obtaining the current time from the network (at startup or later), but the
time is not available, 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.
From: email@example.com [mailto:firstname.lastname@example.org]
Sent: Tuesday, April 27, 1999 15:41
Subject: Re: RE: IPP> Last Call Comment: Job and Printer time attributes
Original Article: http://www.egroups.com/list/ipp/?start=5655
> There are many ways to get a pretty good time value. From sniffing the
> traffic to using a time server. Printers can have their time set via a
> console or web page. They could ask
> "http://tycho.usno.navy.mil/cgi-bin/timer.pl". they could use a GPS
> module...I hear they are getting pretty cheap.
> I do not believe requiring dateTime attributes will be an undue burden on
> printer implementations. It will be useful to IPP client applications.
None of those options sound appealing for really tiny embedded
applications. But you would know better than me about those! Anyway, I
was thinking... We can't count on HTTP requests carrying a Date header, but
we could require an IPP timestamp attribute on every request. Then a
really cheap Printer could get by with a simple clock (a tick counter)
rather than a Real Time Clock, and setting Printer time would be automatic.
Bonus is that IPP Printers wouldn't have to go on the Y2K inventory list.
And no batteries to replace.