I was one of the people that fought for IPP times being measured in seconds
since system initialization. I was concerned about low-end implementations
and consistency with the printer MIB. I now regret that position.
The HTTP layer requires a time stamp. Simple time protocols exist that are
very light weight. A page can be made available in the embedded web server
to set the current date and time. If all else fails the time can be grabbed
from incoming HTTP packets.
My first choice would be to recommend use of date/time attributes for all
timestamps. We should:
1) Deprecate or make optional all time attributes measured in seconds
2) Recommend or mandate equivalent attributes in date/time format.
My second choice would be to add printer-up-time as a mandatory operational
attribute in get-jobs and get-job-attribute operation responses.
Pete
Peter Zehler
XEROX
Networked Products Business Unit
Email: Peter.Zehler@usa.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8792
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 111-02J
Webster NY, 14580-9701
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Tuesday, March 23, 1999 7:31 PM
To: anthony.porter@computer.org; ipp@pwg.org
Subject: RE: IPP> MOD - Use of time [and Bake Off 2 Issue 17]
Anthony Porter's issue about time and suggestions are relevant to ISSUE 17
that was brought up at the IPP BakeOff 2 the week before last and that I
just published yesterday. Please consider and comment on these alternatives
as well as the ones that Anthony Porter has suggested.
Thanks,
Tom
17) ISSUE: Client display of absolute time for job attributes?
What are clients doing with printers that don't support absolute time?
How can client display an absolute time that a job was submitted,
started processing, and completed (which is what is useful for a user)?
Possible Solution
Get Uptime from printer ("printer-up-time" - time system has been up in
seconds)
Get Job(s)
Calculate Display time = job tick time ("time-at-xxx" - in seconds that
system has been up) . uptime ("printer-up-time") + local client absolute
time. The down side is that the client has to get the "printer-up-
time" every time with a separate Get-Printer-Attributes operation.
Alternatively: Add OPTIONAL job attributes: .date-time-at-creation
(dateTime)., .date-time-at-processing (dateTime)., and .date-time-at-
completion (dateTime).
(Issue submitted by Microsoft)
Possible alternatives:
Clarify that the "time-at-xxx" attributes can be negative if an IPP
Printer is re-booted while jobs remain.
1.Add to the IPP/1.1 Model and Semantics document OPTIONAL job
description attributes: .date-time-at-creation (dateTime)., .date-
time-at-processing (dateTime)., and .date-time-at-completion
(dateTime)..
2.Return "printer-up-time" (in seconds) as an operation attribute in
Get-Jobs and Get-Job-Attributes response.
3.Make the "printer-up-time" Printer Description attribute also be a
Job Description attribute. Clients that request the "time-at-xxx"
job attributes should also request the "printer-up-time" job
attribute, so that they can avoid requesting it using a separate Get-
Printer-Attributes request.
-----Original Message-----
From: Anthony Porter [mailto:anthony.porter@computer.org]
Sent: Tuesday, March 23, 1999 02:59
To: ipp@pwg.org
Subject: IPP> Use of time
I have some concerns regarding the use of "printer up time" as the value for
the job "time-at-xxx" attributes. While this simplifies things for small
printers without a clock, it complicates matters for larger systems that do
have a clock.
In the first place, the server must generate negative numbers for historical
jobs that were created or completed before the last power up. The Model and
Semantics spec states that the values must be in the range (0:MAX), so
presumably, this excludes negative numbers.
The second problem is that a client that periodically polls a jobs
attributes will display incorrect times if the printer is restarted in the
meantime. The client would be obliged to query the "printer-up-time"
attribute each time.
The third problem is high-end printing presses are really a collection of
print-units, RIP processors and sundry computers, so they do not have a
unique "printer up time". A press could continue to accept new jobs and RIP
them even though the inky bit was switched off. Such a system could not use
the print unit as a source of printer-up-time, since that would imply that
all jobs created while the print unit is off would have the same
time-at-creation attribute. The system would have to invent a virtual
printer-up-time, perhaps the number of seconds since jan-1-1980.
Would it not be simpler to just use a dateTime value for the "time-at-xxx"
attributes? A simple printer without a clock could then either ignore these
attributes altogether, or return its up time based to 00:00 0/0/0000. If
the printer does not have a clock, it will not be able to return the
printer-current-time attribute either, so the client cannot do very much
with the "time-at-xxx" attributes
Regards,
Anthony Porter