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: From: rbergma@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@pwg.org"@gate.dpc.com ^ ^-missing end of address \-extraneous tokens in address Apparently-To: pwg@pwg.org To: Subject: Updated Definitions for The Job Monitor Project Sender: owner- pwg@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.