TH> I've annoted your updated definitions to tie back to the agreed spec
TH> to help us at the meeting.
TH> I've added the names and numbers of the agreed objects from the
TH> Portland meeting as reflected in the jm-spec.doc and jm-spec.psr
TH> that I posted a week before the August meeting in San Diego
TH> that was cancelled at the last minute.
TH> Then we can use these descriptions as we review the specification
TH> posted in ftp://ftp.pwg.org/pub/pwg/snmpmib/jobs-mib/
TH>
TH> -rw-r--r-- 1 pwg pwg 186368 Aug 22 23:30 jmp-spec.doc
TH> -rw-r--r-- 1 pwg pwg 621572 Aug 22 23:37 jmp-spec.psr
Return-Path: <pwg-owner at pwg.org>
From: rbergma at dpc.com
Date: Thu, 26 Sep 1996 18:42:43 PDT
Illegal-Object: Syntax error in To: address found on alpha.xerox.com:
To: gate"pwg at pwg.org"@gate.dpc.com
^ ^-missing end of address
\-extraneous tokens in address
Apparently-To: pwg at pwg.org
To: <hastings at cp10.es.xerox.com>
Subject: Updated Definitions for The Job Monitor Project Sender: owner-
pwg at pwg.org
This paper summarizes my understanding of the current status of the
proposed objects for the Job Monitor project. I believe that this
document is necessary since the JMP minutes for the last two meeting
were never published.
TH> Not true, since the updated spec with the agreements from June
TH> and July were each posted a week before the next meeting.
TH> see jm-spec.doc and jm-spec.psr.
I have also included a revised set of definitions for the objects to
replace the DPA set originally provided by Tom Hastings. My objective
in writing these descriptions was to develop a minimal definition that
could be expanded to a final form. I feel that the DPA definitions are
extremely restrictive and limiting in many areas. We need a concise set
of definitions that are applicable and useable with any job submission
protocol and model.
TH> I agree that our actual MIB wants to have concise definitions
TH> along the lines that you propose. But I want to first get agreement
TH> on what objects we want and then we can refine, simplify, etc.
TH> But if we attempt to worksmith the descriptions at the same time
TH> as we are trying to decide what objects we need, we will have too
TH> difficult time and progress will be too slow.
TH> Also some of these definitions are actually different from the ISO
TH> DPA semantics.
TH> Also I don't want to debate names of the objects, until we have
TH> the definitions agreed to. Naming should come last. Also we need
TH> to understand what information a single job will have in a
TH> (doubly indexed) table as opposed to a scaler (one column in the job
TH> table) for the job. Separate tables may want to have a different
TH> significant word, such as "job" for the scalars and something else
TH> for the tables, such as "doc", or "acc". or something.
TH> So we need to wait to name our objects until after we agree on the
TH> specification and the number of instances per job.
TH> Also we may want to have a common prefix on each object, such as
TH> "jm" for job monitoring, like so many other MIBs.
TH> So the order for processing should be:
TH> 1. What objects do we want using DPA definitions to indicate what
TH> we mean using jm-spec.doc and jm-spec.psr.
TH> 2. What objects are mandatory, what are conditionally mandatory,
T> what are in a second MIB.
TH> 3. Which objects are one instance per job and which are multiple
TH> per job.
TH> 4. What is the syntax for each object.
TH> 5. What is the simplified description text for each object.
TH> 6. What is the name for each object.
Since I will not be able to attend the NYC meeting, I trust that Tom
Hastings will make use of this document in the session devoted to the
Job Monitor Project. (Note that my absence is not due to a fear of the
Big Apple, the expense of the meeting or the limited attendance by
others. I was not able to attend the San Diego meeting due to a similar
situation. And that meeting had none of the above problems!) I hope to
see everyone in New Orleans!!!
TH> I've indicated the agreed descriptive name with the
TH> number in the August agreed spec, followed by the ISO DPA name
TH> in square brackets.
------------------------------------------------------------------------
JOB IDENTIFICATION OBJECTS:
TH> 1. Job client id (on the original client) [job-client-id]
1. jobIdOnClient: (String, max TBD) This object identifies the job on
the device that initiated the job. The format and method of generating
this object is expected to be defined by the Job Submission protocol and
is beyond the scope of this document. This object must include
sufficient information to uniquely identify the job on the network
visible to the client and target device.
*** THE FOLLOWING TWO OBJECTS ARE OF QUESTIONABLE VALUE ***
TH> 4. Job downstream id (downstream from the server implementing this
JM MIB) on device (printer [job-identifier-on-printer]
2. jobDownsteamId: (String, max TBD) This object identfies the job on
the next downstream server.
TH> 2. Job upstream id (on upstream from the server implementing thise
JM MIB) [job-id-on-client]
3. jobUpstreamId: (String, max TBD) This object identfies the job on
the next upstream server.
*** PROPOSED ALTERNATIVES TO THE ABOVE TWO OBJECTS *** 2.
jobIdOnPktSrc: (String, max TBD) This object specifies the identifier
as assigned by the entity that is currently sending the data set. The
value of this object will change as the data set moves from server to
server.
3. jobIdOnPktDest: (String, max TBD) This object specifies the
identifier as assigned by the entity that is currently receiving the
data set. The value of this object will change as the data set moves
from server to server.
*** ARE EITHER OF THESE PROPOSALS REALLY NECESSARY ??? ***
TH> 3. Job current id (on the downstream server implementing thise JM
MIB) [job-identifier]
4. jobIdOnDevice: (String, max TBD) This object identifies the job on
the device which is currently processing the job. The processing device
includes, but is not limited to, printers, faxes, scanners, spoolers,
and files servers. The value of this object may change for systems that
include intermediate devices such as file servers and spoolers.
TH> 5. Job types (print, fax, scan, etc.) - multi-valued [new]
5. jobType: (enum) This object specifies the type of service requested
to process the job.
TH> 6. Job owner (User name that originally submitting print job) [new]
6. jobOwner: (String, max TBD) This object identifies the client that
submitted the job. The method of assigning this name will be system
and/or site specific but the method must insure that the name is unique
to the network visible to the client and target device.
TH> 7. Source channel type (index of channel row in enum from Printer
MIB) [new]
7. jobChannel: (enum) This object defines an equivalent to the print
job delivery channel as defined in the Printer MIB.
TH> ?. This is new but replaces the "source port" that we agreed to
TH> delete in Portland.
8. jobMagicCookie: (??) This object defines the protocol path from the
physical layer to the jobChannel. The format of this object will be
similar to the work in process for the Printer MIB.
TH> 9. Job name (assigned by job owner) [job-name]
9. jobName: (String, max TBD) This object is an ASCII text string which
identifies the job. This is expected to be human readable form of
jobIdOnClient.
*** IS THIS OBJECT SIGNIFICANTLY UNIQUE TO BE OF VALUE ??? ***
TH> Its purpose isn't uniqueness, but helps a user distinguish between
TH> his various jobs. Its job-owner that distinguishes between jobs
TH> belonging to different users.
TH> 10. Document name(s) (or file-names) [document-name]
10. jobDocument: (String, max TBD) This object defines a name for the
job. The name is typically expected to be the file or file/path name of
the source of the job. The name does not need to be globally unique.
(The name would typically be repeated if several jobs from the same file
are simultaneously in the jon queue.)
TH> 11. Date/Time of job submission by job owner [submission-time]
11. jobSubmissionTime: (DateAndTime) This object indicates the time and
date the job was submitted by the client.
TH> 12. Job comment [job-comment]
12. jobComment: (String, max TBD) This object provides a user
defineable, application specific field. (Post-it note)
TH> 13. Device name (Device-specific name of device) [printer-name-
requested]
13. jobDeviceName: (String, max TBD) This object specifies the
administratively defined name of the target device.
JOB PARAMETERS:
*** THE VALUE OF THESE PARAMETERS HAS BEEN QUESTIONED, ***
*** SINCE THIS IS NOT A JOB SUBMISSION PROTOCOL ***
*** PROPOSE THAT ONLY THE ITEMS THAT INDICATE STATUS OR ***
*** PROVIDE ACCOUNTING INFORMATION BE RETAINED !!! ***
TH> 1. Number of copies requested [job-copies]
1. jobCopiesRequested (Integer32)
TH> 2. Media path requested (one-sided, two-sided, LEF, SEF) [one value
for each document]
2. jobMediaPathRequested (enum)
TH> 3. PDLs requested [one value for each document] [document-format]
3. jobPDLRequested (enum)
TH> 4. Job priority [job-priority]
4. jobPriorityRequested (Integer)
TH> 5. Resource types requested, including media, finishing, color ink.
TH> Presumably a type (enum) indicating the kind of resource.
TH> Relates to Consumables consumed. TH> [new]
5. jobResourceRequested (enum)
TH> 6. Resource names requested [new]
6. jobResourceNamesRequested (String)
TH> 7. Destination (including phone numbers for FAX, logical printers
for printing) [new]
7. jobDestinationRequested (String)
TH> 8. process-after-time [job-print-after]
8. jobProcessAfterTime (TimeAndDate)
TH> 9. job-message-to-operator from submitting user or device [job-
TH> message-to-operator]
9. jobMessageToOperator (String)
STATUS AND ACCOUNTING PARAMETERS:
TH> 1. Job state (held, pending, processing, completed, etc.) [current-
TH> job-state]
1. jobState (enum ?) This object defines the current state of the job.
(e.g. queued, printing, completed, etc.)
TH> 3. Job state reasons [job-state-reasons]
2. jobStateReason (bit map) This object provides additional information
regarding the the jobState.
TH> 2. Physical device(s) being used [printers-assigned]
3. jobDeviceUsed (hrDeviceIndex) This object identifies the physical
device or devices used to complete the job.
*** FURTHER WORK IS REQUIRED TO DEFINE THIS OBJECT AND ***
*** ITS RELATION TO THE REMAINING OBJECTS !!! ***
*** SHOULD A SEPARATE PACKET BE RETURNED FOR EACH DEVICE OR ***
*** TRY TO COMBINE ALL INTO ONE ??? ***
*** HOW IS ALL THIS INFORMATION TO BE COMBINED ??? ***
TH> 4. Job State Reason Message [new]
not in Ron's list
TH> 5. Octets completed [octets-completed]
4. jobOctetsCompleted (Counter64) This object defines the number of
octetes currently processed by the device. For multiple copies
generated from a single data stream, the value shall be incremented as
if each copy was printed from a new data stream without resetting the
count between copies.
TH> Objects 5, 6, and 7 were merged into consumables consumed in
TH> jm-spec.
*** OBJECTS 5, 6, AND 7 WILL BE A TABLE WITH AN ENTRY FOR EACH ***
*** MEDIA TYPE USED. ***
5. jobMedia (?) This object indicates the media used for this table
entry. I propose that this be the prtInputIndex. Information regarding
the media can then be obtained from the Printer MIB.
TH> 6. Impressions (sides) complete [impressions-completed]
6. jobImpressionsCompleted (Counter32) This object defines the total
number of sides that have been completed for this job. Each physical
sheet has two possible side. (i.e. For a duplex printing job, the
number of impressions will be 2 for each physical sheet printed on both
sides.)
TH> 7. Sheets completed [media-sheets-completed]
7. jobMediaSheetsCompleted (Counter32) This object defines the total
number of physical sheets that have been completed for this job.
TH> 8. Processing time completed [processing-time]
8. jobProcessingTimeCompleted (Counter32) This object defines the
processing time, in seconds, consumed by the job.
TH> 9. Date/Time of day job started processing on device [started-
TH> printing-time]
9. jobStartingTime (DateAndTime) This object indicates the time the job
started printing.
TH> 10. Date/Time of day job finished using the device [completed-time]
10. jobCompletionTime (DataAndTime) This object defines the time the job
finished printing.
TH> 11. Warning count [warning-count]
11. jobWarningCount (Counter32) This object contains a count of the
number of warning events that occurred during the processing of the job.
TH> 12. Error-count [error-count]
12. jobErrorCount (Counter32) This object contains a count of the
number of error events that occurred during the processing of the job.
TH> 13. Number of pending jobs currently scheduled to process before
TH> this job [intervening-jobs]
13. jobPositionInQueue (Counter32) This object indicates the number of
jobs preceeding this job in the print queue.
TH> 14. Account Name [accounting-information]
14. jobAccountName (String, max TBD) This object contains information
to be used by an accounting system to categorize charges.
*** OBJECTS 15, 16, 17 AND 18 WILL BE A TABLE WITH AN ENTRY ***
*** FOR EACH CONSUMABLE USED. ***
TH> 15. Consumables consumed [new]
15. jobConsumableId (enum) This object defines the resource used.
TH> 16. consumable name [new]
16. jobConsumableName (String, max TBD) This object provides an ASCII
text string which describes the consumable.
TH> 17. consumable-unit [new]
17. jobConsumableUnit (enum) This objects defines the units of measure
for the consumable.
TH> 18. amount-consumed [new]
18. jobConsumableUsed (Integer32) This object indicates the amount of
the resource consumed.
TH> 19. PDLs used [document-format]
19. pdlUsed (enum) This object defines the PDL(s) used by the job.