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

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

Anthony Porter anthony.porter at computer.org
Wed Apr 28 04:07:34 EDT 1999


Tom,
In order to get a complete picture of how the job is progressing, the user
would like to know the time at which the job started and finished ripping
(or interpreting) as well as the time at which it started and finished
marking.  It is not uncommon for user to send jobs of several hundred MBytes
to our systems.

It seems that the "time-at-xxx" attributes are primarily intended for
printers without clocks, while the "date-time-at-xxx" attributes simplify
things for printers with clocks and their clients.  Printers with separate
rip processors have clocks, so perhaps it is better to leave the
"time-at-xxx" attributes as they are and add optional
"date-time-at-interpreted" and "date-time-at-marking" attributes.  These
times could overlap, because the system might start marking before it has
finished interpreting.

The problem with this is that printers that do not make a distinction
between processing and marking could implement one or the other, and this
makes it difficult for clients.  Also, if these attributes are optional,
most clients will probably just display the date-time-at-creation,
date-time-at-processing and date-time-at-completed, if this is what the
majority of office printers support.

I think that the date-time-at-xxx attributes ought to be optional as a
group, so that servers implement all 5 or none of them.  If the server makes
no distinction between processing and marking, then date-time-at-marking
would be the same as date-time-at-processing and date-time-at-interpreted
would be the same as date-time-at-completed.

IPP is going to make these high-end printers just as accessible to the
general public as the generic office printers, so perhaps it is worth
supporting their features, if it is not too difficult.

Anthony
-----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 7:34 PM
To: anthony.porter at computer.org; 'Hastings, Tom N'; 'ipp'
Subject: RE: IPP> MOD - part of Issue 17 - don't need negative
"time-at-xxx" Job Attributes


I think you are proposing that we add OPTIONAL "time-at-marking (integer)"
and OPTIONAL "date-time-at-marking (dateTime)", correct?  Should we add such
attributes?

So the "time-at-processing (integer)" and "date-time-at-processing
(dateTime)"
remain when the job first enters the 'processing' state, as currently
specified which in your case is 'ripping', correct?

Or are you suggesting that we change the definition of "time-at-processing
(integer)" and "date-time-at-processing (dateTime)" attributes so that they
may be updated when the job starts marking for implementations that have a
large time between ripping and marking?

Thanks,
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