IPP Mail Archive: RE: IPP> MOD - REVISITED Issue 17 - Client display of absolute da

RE: IPP> MOD - REVISITED Issue 17 - Client display of absolute da

Hastings, Tom N (hastings@cp10.es.xerox.com)
Mon, 10 May 1999 21:12:34 -0700

Our intent was not to invalidate implementations. Also it seems that we
need to clarify the difference between the Printer object software and the
device(s).

So we propose the following clarification to allow your Printer object
implementation (in the PC) to continue without having to reset the time.
However, for those implementations where the MIB-II sysUpTime is reset on
power up or the Printer MIB, such implementation MAY want to reset the
"printer-up-time" attribute.

So how does this sound:

If the Printer object software ceases running, and restarts without knowing
the last value for "printer-up-time", the implementation MUST reset this
value to 1. However, if the device or devices that the Printer object is
representing are restarted or power cycled, the Printer object MAY continue
counting this value or MAY reset this value to 1 depending on
implementation. If this value is reset and the implementation has
persistent jobs and the Event Time Job Description Attributes are
represented using the 'integer' form (instead of the 'dateTime' form), they
MUST be reset according to Section 4.3.12.

-----Original Message-----
From: Anthony Porter [mailto:anthony.porter@computer.org]
Sent: Monday, May 10, 1999 00:54
To: 'Hastings, Tom N'; 'ipp'
Subject: RE: IPP> MOD - REVISITED Issue 17 - Client display of absolute
date and time for job attributes

Well, it looks as if my implementation is in error, because 4.4.27 says that
the implementation MUST reset the value to 1 and it doesn't.

Another case would be an IPP server running on a PC that looks after a
couple of simple printers connected to the PC. Each printer in independent
and has its own IPP URL, so from a client they look like two IPP servers.

If one of those printers is reset, the IPP server probably wouldn't know and
so would not reset the printer-up-time. That was OK in IPP 1.0, since it
was the equivalent of method 1, but it would be wrong in IPP 1.1 because
4.4.27 says that printer-up-time MUST be reset.

For the client of course, it does not make any difference, it is as if the
printer did not go down at all. The only problem is with these pesky QA
guys who turn the printer off and on and then complain that the
implementation does not reset printer-up-time to 1 like it says in 4.4.27.

I don't think that the spec ought to require that printer-up-time be reset,
it is enough to say that IF the printer has to reset printer-up-time
following a restart, it must reset the value to 1 and not 0.

Anthony
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: 07 May 1999 17:40
To: anthony.porter@computer.org; 'Hastings, Tom N'; 'ipp'
Subject: RE: IPP> MOD - REVISITED Issue 17 - Client display of absolute
date and time for job attributes

I think this still means that its ok to delete method 1 from IPP/1.1, since
you never reset the "printer-up-time" attribute and so the job time tick
attributes
("time-at-xxx") never need adjustment.

Correct?

In other words, if the printer never goes down, then the "printer-up-time"
is still the time since the Printer object was started.

So the following proposed description for "printer-up-time" will not impact
your implementation, correct:

4.4.27 printer-up-time (integer(1:MAX))

This REQUIRED Printer attribute indicates the amount of time (in seconds)
that this Printer instance has been up and running. The value is a
monotonically increasing value starting from 1 when the Printer object is
started-up (initialized, booted, etc.). This
value or the value of "printer-current-time" is used to populate the Job
attributes "time-at-creation", "time-at-processing", and
"time-at-completed", depending on implementation (see Section 4.3.12).

If the Printer object ceases running and restarts, the implementation MUST
reset this value to 1.

Thanks,
Tom