You said:
>The job-hold-until attribute depends on the time-zone, so a printer that
>supports the "printer-current-time" attribute should support its local
>time zone.
Good point.
In other words, the time zone offset that comes back when a client queries
the "printer-current-time" SHOULD/MUST be the local time of the printer.
If we clarify the "printer-current-time" this way, then a client could also
use the "printer-current-time" to determine the time zone of the Printer,
whether the "job-hold-until" attribute is supported or not. Something that
might be useful for the user submitting a job.
So we should change the clarifying sentence that I added to
"printer-current-time" from:
The time zone in this value NEED NOT be the time zone of the Printer object
or device. Therefore, the vendor MAY ship the implementation using GMT, for
example, with no way to change the time zone. The client SHOULD display any
dateTime attributes using the time zone of the client.
to:
The time zone in this value SHOULD be the time zone of the Printer object
or device. Then the client can use this attribute to determine the time
zone of the printer, even though clients SHOULD display any dateTime
attributes to users using the time zone of the client.
Ok to make this a SHOULD, instead of a MUST?
Other comments?
Tom
-----Original Message-----
From: Anthony Porter [mailto:anthony.porter at computer.org]
Sent: Tuesday, April 27, 1999 00:57
To: 'Hastings, Tom N'; 'ipp'
Subject: RE: IPP> MOD - part of Issue 17 - don't need negative
"time-at-xxx" Job Attributes
My printer is a networked collection of bits, so the "printer-up-time' is
going to be the time since some fixed date in the past.
It is a pity there is no distinction between time-at-processing and
time-at-marking. I shall stamp the time-at-processing when the job goes to
the RIP(interpreter) but it could be a long time, even days before the job
goes to the marking bit of the printer. ( The shop might have run out of
the A4 printing media required for this particular job).
The job-hold-until attribute depends on the time-zone, so a printer that
supports this attribute should support its local time zone.
Anthony Porter
-----Original Message-----
From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of Hastings,
Tom N
Sent: Tuesday, 27 April, 1999 12:52 AM
To: ipp
Subject: IPP> MOD - part of Issue 17 - don't need negative "time-at-xxx"
Job Attributes
While writing up the part of Issue 17 about clarifying that the time-at-xxx
Job attributes MAY be negative after a restart for systems that keep jobs
persistently, I discovered that the "printer-up-time" Printer Description
attribute has already dealt with the problem of restarts in a different way.
The value of the "time-at-xxx" is reset to 0 and stays there for each
persistently held job on a restart. The following text is in the June 1998
Model. I added the last sentence to clarify that an implementation could
use both methods depending on the type of restart.
So ok NOT to change the "time-at-xxx" Job attributes from "time-at-xxx"
(integer(0:MAX)) to "time-at-xxx" (integer(MIN:MAX))? To help, I'll add a
reference to each of the "time-at-xxx" attributes to the "printer-up-time"
attribute, so that implementer's will see the restart explanation.
4.4.26 printer-up-time (integer(1:MAX))
This REQUIRED Printer attribute indicates the amount of time (in seconds)
that this instance of this Printer implementation has been up and running.
This value is used to populate the Job attributes "time-at-creation",
"time-at-processing", and "time-at-completed". These time values are all
measured in seconds and all have meaning only relative to this attribute,
"printer-up-time". The value is a monotonically increasing value starting
from 1 when the Printer object is started-up (initialized, booted, etc.).
If the Printer object goes down at some value 'n', and comes back up, the
implementation MAY:
1. Know how long it has been down, and resume at some value greater
than 'n', or
2. Restart from 1.
In the first case, the Printer SHOULD not tweak any existing related Job
attributes ("time-at-creation", "time-at-processing", and
"time-at-completed"). In the second case, the Printer object SHOULD reset
those attributes to 0. If a client queries a time-related Job attribute and
finds the value to be 0, the client MUST assume that the Job was submitted
in some life other than the Printer's current life. An implementation MAY
use both cases, depending on warm versus cold start, respectively.
I've also added the two last paragraphs to "printer-current-time", the first
relating to the 3 new "date-time-at-xxx (dateTime)" Job Description
attributes that Issue 17 is adding, and the second to clarify that the time
zone need not be that of the device. Ok?
4.4.27 printer-current-time (dateTime)
This Printer attribute indicates the current absolute wall-clock time. If
an implementation supports this attribute, then a client could calculate the
absolute wall-clock time for each Job's "time-at-creation",
"time-at-processing", and "time-at-completed" attributes by using both
"printer-up-time" and this attribute, "printer-current-time". If an
implementation does not support this attribute, a client can only calculate
the relative time of certain events based on the REQUIRED "printer-up-time"
attribute.
If an implementation supports this attribute, then this value is used to
populate the Job attributes "date-time-at-creation",
"date-time-at-processing", and/or "date-time-at-completed" Job attributes.
ISSUE 17
The time zone in this value NEED NOT be the time zone of the Printer object
or device. Therefore, the vendor MAY ship the implementation using GMT, for
example, with no way to change the time zone. The client SHOULD display any
dateTime attributes using the time zone of the client.