Keith,
I've either incorporated your comments into the Internet Draft 00 (rev 0.71)
or added them to the issues list as indicated.
Tom
At 13:39 02/04/97 PST, kccarter at vnet.ibm.com wrote:
>JMP Team,
>>Here is my belated assessment of the Job Monitoring MIB
>document (version 0.6, dated 01/23/97) which we can discuss
>further at our JMP meeting in San Jose. Thanks to Tom
>Hastings for producing this document!
>>* Page 7 - Job Object Lifecycle Summary: Please add a
>State for "Printing" to indicate that the job is currently
>printing on the printer.
I added job-printing as a JmJobStateReasons enum to align with IPP
and to keep the job states aligned between IPP and the JMP. Ok?
An additional advantage is that implementations that don't want to distinguish
between processing and printing, don't need to.
>>* Page 22 - MIB Datatype specifications: This is a nit,
>but it would be helpful to give an example of the format for
>DateAndTime. For example, how does one specify 12:01:00AM on
>Thursday, January 30, 1997?
Done. DateAndTime is a binary 8 or 11 octet format.
>>* Page 25 - jmQueueAlgorithmTC: I agree with the
>resolution of issue 15 and 16 which states that this object
>will be removed from the Job MIB.
Done.
>>* Page 28 - jmJobStateTC: Please add a State for
>"printing" to indicate that the job is currently printing on
>the printer.
>
I added job-printing as a JmJobStateReasons enum to align with IPP.
and to keep the job states aligned between IPP and the JMP. Ok?
An additional advantage is that implementations that don't want to distinguish
between processing and printing, don't need to.
>* Page 31 - jmJobStateReasonsTC: Please confirm that state
>"completion" plus reason "successfulCompletion" means that
>all pages of the print job have been successfully printed
>and stacked in the output bin. If so, we're set. If not,
>then please add "jobStacked" to indicate the reason for the
>"completion" state is that all pages in the job have been
>stacked in the output bin of the printer.
Good clarification. I agree that complete and retained states both
mean that all media has been sucessfully stacked. See Internet Draft 00
to see if the clarification is understandable.
>>* Page 42 - jmResourceTypeTC: I agree with the resolution
>of issue 22 which states that "faxPhoneNumber" will be
>removed from the Job MIB.
Done.
>>* Page 42/43 - impressionsCompleted and sheetsCompleted:
>How does number of copies affect these values?
Number up divides these numbers by n.
>>* Page 43 - jmResourceTypeTC: In OS/2 Warp,
>"pagesSpooled", "pagesSentToDevice" and "pagesCompleted"
>mean "impressions" - not "logical pages". Therefore, please
>change the name of these resources to "impressionsSpooled"
>and "impressionsSentToDevice". Please change the
>description from "logical pages" to "impressions". Please
>indicate that "impressionsSpooled" is for 1 copy of a job
>and "impressionsSentToDevice" is reset to 1 for each copy.
>"pagesCompleted" can be removed since it equals
>"impressionsCompleted". In OS/2 Warp,
>"impressionsCompleted" is reset to 1 for each copy of a job.
Done. There is now the following impression (more), pages,
and sheet attributes (from the TOC):
impressionsSpooled 60
impressionsSentToDevice 60
impressionsInterpreted 60
impressionsRequested 60
impressionsCompleted 60
impressionsCompletedCurrentCopy 60
pagesRequested 60
pagesCompleted 60
pagesCompletedCurrentCopy 60
sheetsRequested 61
sheetsRequested 61
sheetsCompleted 61
sheetsCompletedCurrentCopy 61
>>* Page 43 - jmResourceTypeTC: Does "processingTime" count
>operator intervention time? (e.g. the time a job was held
>up due to a paper jam on the printer)
No it should not, so that the time is reproducible and fair.
I changed the name to processingCPUTime to clarify and added why.
>>* Page 49 - Should MIB provide jmGeneralNumberOfJobsQueued
>and jmGeneralNumberOfJobsComplete so a network management
>application can summarize the current status of the printer?
Yes. I added:
jmGeneralNumberOfJobsToComplete 65
jmGeneralNumberOfJobsCompleted 66
>>* Page 49 - jmGeneralQueuingAlgorithm: I agree with the
>resolution of issue 28 which states that this object will be
>removed from the Job MIB.
Done.
>>* Page 53 - jmJobMessageToOperator: It doesn't appear
>anyone supports this. Should this object be removed from
>the Job MIB?
Gone as agreed.
>>* Page 58 - jmJobName, jmJobIdName, jmJobIdNumber,
>jmJobComment: Clarify the use of these objects. Here is an
>example. A user submits a print job. The file name of the
>job is "C:\MYJOB.PS". The user specifies a comment of
>"Status Report 1/31/97". The print job is queued on server
>"SERVER1" in print queue "PSQUEUE". The numeric job id is
>1234. What value is the value of each object? Do we need a
>specific object for source server and source queue to
>accommodate management applications such as the management
>application provided by HP that correlates jobs in a printer
>with jobs in a print queue on a print server?
I think that jmJobComment is intended for more free form "on the spot"
text, such as the user reminding him/herself what to do with the output
or indicating differences between several submissions, if trying different
features of the system, while jmJobName is more of a name and defaults
from the document name or file name. In IPP jmJobName cannot be set by
the client, only defaulted by the Printer from the document name or file name.
See if my clarifications of jobComment attribute and the jmJobName object
help.
For the other objects, I agree we need to continue the discussion as HP
points out for each of our configurations. The other questions and
issues are issues 59-61.
>>* Page 59 - jmJobIdNumber: OS/2 uses -1 to indicate there
>is not a job id. I recall seeing -2 in one of the Job MIB
>specs. Why not use -1 instead of -2?
-2 is a convention from the Printer MIB for unknown. -1 is for other.
They correspond to enums other(1) and unknown(2). A WARP agent will
have an easy time mapping the WARP -1 to the JMP -2 on a Get operation.
>>* Page 59 - jmJobTypes: It doesn't appear anyone supports
>this object. Is this object intended for a multi-function
>device (MFD) so the host can inform the MFD which of its
>devices to direct the job?
As JMP agreed, it is there for the future when this MIB is augmented
or extended for non-printing services. For a printer, the object can
be implemented as a hard-coded print(4). We could move it to the
attributes table. Should we?
>>* Page 60 - jmJobDeviceNameRequested: What is the purpose
>of this object? Is this the name of the printer (e.g.
>make and model)?
No. Its purpose is the fundamental input parameter that the end-user
supplies to indicate on which printer the job is to be printed. For
systems where the user specifies a queue, then this object is the queue
name that the user supplied. To further clarify this, I've changed
the name to: jmJobDeviceNameOrQueueRequested
>>* Page 60 - jmJobDeviceIndex: What value should a print
>server return if it doesn't support the printer mib?
Since we moved this object to the attributes table, a server wouldn't
return this attribute. Had it remained as an object in the Job Table,
the server agent would have returned a 0, which is an illegal index value
in SNMP.
>>* Page 61 - jmJobSourceChannel: What are the enum values
>referred to in issue 37?
These are enums in the Printer MIB indicating the type of job submission
channel.
>>Keith
>>