IPP> MOD - part of Issue 17 - don't need negative "time-at-xx x" Job Attributes

IPP> MOD - part of Issue 17 - don't need negative "time-at-xx x" Job Attributes

IPP> MOD - part of Issue 17 - don't need negative "time-at-xx x" Job Attributes

Herriot, Robert Robert.Herriot at pahv.xerox.com
Tue Apr 27 16:03:13 EDT 1999


I don't think that we can mandate what the time zone should or must be.

A printer vendor can certainly set a printer's clock (if it exists) to the
correct time in some time zone at time of manufacture. GMT is likely the
best choice for the time zone. But a vendor cannot know what time zone a
printer is going to be installed in, nor does it matter. A customer may want
to change the time zone or may not care to bother.

A client must be able to translate a received time, which must include a
timezone, into a local time. But a client should not expect for the received
times to say anything about the time zone used by people near the printer.
That is overloading the intent of the time attributes which is intended to
give the absolute time of occurrence of various events. 

As for "job-hold-until", it is certainly ambiguous whether "evening" is
relative to the client or server. Because there is no requirement that a
client tell the server about its time zone, the "job-hold-until" attribute
must be relative to the server.  Because the model document doesn't specify
what "evening" or any other time period means, a client cannot infer from a
"printer-current-time" clock when evening is. It might likly be somewhere in
the range of 1700-2400, but the model is purposefully silent on this issue.

Bob Herriot


-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Tuesday, April 27, 1999 11:30 AM
To: anthony.porter at computer.org
Cc: 'ipp'
Subject: RE: IPP> MOD - part of Issue 17 - don't need negative
"time-at-xx x" Job Attributes


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.



More information about the Ipp mailing list