RFC 2707
Job Monitoring MIB - V1.0
Job Monitoring MIB - V1.0 🖨️✨
Okay bestie, here's the full tea on this one 🫶. It's RFC 2707, filed under the Network Working Group as Informational 📄 and dated November 1999. The writing squad is R. Bergman (Dataproducts Corp.), T. Hastings, Ed. (Xerox Corporation), S. Isaacson (Novell, Inc.), and H. Lewis (IBM Corp.) 💅. It doesn't list any RFCs it obsoletes or updates, so it's standing on its own 🦋.
Status of this Memo 💅
Quick vibe check: this memo is information only 🧚. It is not an Internet standard of any kind, and distribution is unlimited, so share away 🌸.
Copyright Notice 🎀
Copyright (C) The Internet Society (1999). All Rights Reserved 💖
IESG Note 🙈
Okay, this one's a little spicy 🌶️. This MIB module models management information in its own unconventional way, layered on top of the SNMP model, and that approach is unique to this MIB 🧩.
The IESG recommends against using this document as an example for the design of future MIBs. 💀
Also, the "Printer Working Group" is an industry consortium, not an IETF working group 🏢. The IETF doesn't recognize it as a standards-setting body. This document is only being published to inform the Internet community about a MIB that might show up in the marketplace, and publishing it as an RFC is not an endorsement of the MIB 🙅♀️.
Abstract ✨
This document describes a printer-industry standard SNMP MIB for four jobs 🖨️: (1) monitoring the status and progress of print jobs, (2) getting resource requirements before a job gets processed, (3) tracking resource consumption while a job is being processed, and (4) collecting resource accounting data once a job is done 📊.
The MIB is meant to be implemented either (1) in a printer or (2) in a server that supports one or more printers 🌈. Using the object set isn't limited to printing, but support for services other than printing is outside the scope of this Job Monitoring MIB 🚫. Future extensions might cover things like fax machines and scanners 📠, though that isn't limited to them either 🧚.
Table of Contents 📚
1 INTRODUCTION 4
1.1 Types of Information in the MIB 5
1.2 Types of Job Monitoring Applications 6
2 TERMINOLOGY AND JOB MODEL 7
2.1 System Configurations for the Job Monitoring MIB 11
2.1.1 Configuration 1 - client-printer 11
2.1.2 Configuration 2 - client-server-printer - agent in the
server 12
2.1.3 Configuration 3 - client-server-printer - client
monitors printer agent and server 14
3 MANAGED OBJECT USAGE 15
3.1 Conformance Considerations 15
3.1.1 Conformance Terminology 16
3.1.2 Agent Conformance Requirements 16
3.1.2.1 MIB II System Group objects 17
3.1.2.2 MIB II Interface Group objects 17
3.1.2.3 Printer MIB objects 17
3.1.3 Job Monitoring Application Conformance Requirements 17
3.2 The Job Tables and the Oldest Active and Newest Active
Indexes 18
3.3 The Attribute Mechanism and the Attribute Table(s) 20
3.3.1 Conformance of Attribute Implementation 21
3.3.2 Useful, 'Unknown', and 'Other' Values for Objects and
Attributes 21
3.3.3 Index Value Attributes 22
3.3.4 Data Sub-types and Attribute Naming Conventions 22
3.3.5 Single-Value (Row) Versus Multi-Value (MULTI-ROW)
Attributes 23
3.3.6 Requested Objects and Attributes 23
3.3.7 Consumption Attributes 24
3.3.8 Attribute Specifications 24
3.3.9 Job State Reason bit definitions 43
3.3.9.1 JmJobStateReasons1TC specification 44
3.3.9.2 JmJobStateReasons2TC specification 47
3.3.9.3 JmJobStateReasons3TC specification 51
3.3.9.4 JmJobStateReasons4TC specification 51
3.4 Monitoring Job Progress 51
3.5 Job Identification 55
3.5.1 The Job Submission ID specifications 56
3.6 Internationalization Considerations 60
3.6.1 Text generated by the server or device 61
3.6.2 Text supplied by the job submitter 61
3.6.3 'DateAndTime' for representing the date and time 63
3.7 IANA and PWG Registration Considerations 63
3.7.1 PWG Registration of enums 63
3.7.1.1 Type 1 enumerations 64
3.7.1.2 Type 2 enumerations 64
3.7.1.3 Type 3 enumeration 64
3.7.2 PWG Registration of type 2 bit values 65
3.7.3 PWG Registration of Job Submission Id Formats 65
3.7.4 PWG Registration of MIME types/sub-types for document-
formats 65
3.8 Security Considerations 65
3.8.1 Read-Write objects 65
3.8.2 Read-Only Objects In Other User's Jobs 66
3.9 Notifications 66
4 MIB SPECIFICATION 67
Textual conventions for this MIB module 68
JmUTF8StringTC 68
JmJobStringTC 68
JmNaturalLanguageTagTC 68
JmTimeStampTC 69
JmJobSourcePlatformTypeTC 69
JmFinishingTC 70
JmPrintQualityTC 71
JmPrinterResolutionTC 71
JmTonerEconomyTC 72
JmBooleanTC 72
JmMediumTypeTC 72
JmJobCollationTypeTC 74
JmJobSubmissionIDTypeTC 74
JmJobStateTC 75
JmAttributeTypeTC 78
JmJobServiceTypesTC 81
JmJobStateReasons1TC 83
JmJobStateReasons2TC 83
JmJobStateReasons3TC 83
JmJobStateReasons4TC 84
The General Group (MANDATORY) 84
jmGeneralJobSetIndex (Int32(1..32767)) 85
jmGeneralNumberOfActiveJobs (Int32(0..)) 86
jmGeneralOldestActiveJobIndex (Int32(0..)) 86
jmGeneralNewestActiveJobIndex (Int32(0..)) 86
jmGeneralJobPersistence (Int32(15..)) 87
jmGeneralAttributePersistence (Int32(15..)) 87
jmGeneralJobSetName (UTF8String63) 88
The Job ID Group (MANDATORY) 88
jmJobSubmissionID (OCTET STRING(SIZE(48))) 89
jmJobIDJobSetIndex (Int32(0..32767)) 90
jmJobIDJobIndex (Int32(0..)) 91
The Job Group (MANDATORY) 91
jmJobIndex (Int32(1..)) 92
jmJobState (JmJobStateTC) 92
jmJobStateReasons1 (JmJobStateReasons1TC) 93
jmNumberOfInterveningJobs (Int32(-2..)) 93
jmJobKOctetsPerCopyRequested (Int32(-2..)) 94
jmJobKOctetsProcessed (Int32(-2..)) 94
jmJobImpressionsPerCopyRequested (Int32(-2..)) 95
jmJobImpressionsCompleted (Int32(-2..)) 96
jmJobOwner (JobString63) 96
The Attribute Group (MANDATORY) 97
jmAttributeTypeIndex (JmAttributeTypeTC) 98
jmAttributeInstanceIndex (Int32(1..32767)) 99
jmAttributeValueAsInteger (Int32(-2..)) 99
jmAttributeValueAsOctets (Octets63) 100
5 APPENDIX A - IMPLEMENTING THE JOB LIFE CYCLE 104
6 APPENDIX B - SUPPORT OF JOB SUBMISSION PROTOCOLS 105
7 REFERENCES 105
8 NOTICES 108
9 AUTHORS' ADDRESSES 109
10 INDEX 111
11 Full Copyright Statement 1141. Introduction ✨
okay bestie, so this spec defines an official Printer Working Group (PWG) [PWG] standard SNMP MIB for monitoring jobs on network printers 🖨️💖. It's published as an IETF Information Document so the whole Internet community can use it 🌸. The IETF Application Area Directors were consulted, and they concluded that this MIB properly belongs as an Information document, because it monitors a service node on the network rather than a network node proper 🧚.
The Job Monitoring MIB is meant to be implemented by an agent inside a printer, or by the first server closest to the printer. That applies when the printer is directly connected to only that server, or when the printer doesn't have a job monitoring MIB agent of its own 🎀. It is recommended that implementations place the SNMP agent as close as possible to the processing of the print job. This MIB works for printers with and without spooling 🖨️. It's also designed to be compatible with most current commonly-used job submission protocols. In most environments that support high-function job submission/job control protocols, like ISO DPA [iso-dpa], those protocols would be used to monitor and manage print jobs instead of the Job Monitoring MIB 💅.
The Job Monitoring MIB has four groups: a General Group, a Job Submission ID Group, a Job Group, and an Attribute Group ✨. Each group is a table, and all accessible objects are read-only 🔒. The General Group holds general info that applies to all jobs in a job set. The Job Submission ID table maps the job submission ID that the client uses to identify a job to the jmJobIndex that the Job Monitoring Agent uses to identify jobs in the Job and Attribute tables 🦋. The Job table contains the MANDATORY integer job state and status objects 👑. The Attribute table has multiple entries per job, specifying (1) job and document identification and parameters, (2) requested resources, and (3) consumed resources during and after job processing/printing 📚. A larger number of job attributes are defined as textual conventions. An agent SHALL return these if the server or device implements the functionality and the agent has access to the information 🫶.
1.1 Types of Information in the MIB
okay so the job MIB is meant to give the following info to the indicated Role Models in the Printer MIB [print-mib] (Appendix D - Roles of Users) 🌈.
- User:
- Provide the ability to identify the least busy printer. The user will be able to determine the number and size of jobs waiting for each printer. No attempt is made to actually predict the length of time that jobs will take.
- Provide the ability to identify the current status of the user's job (user queries).
- Provide a timely indication that the job has completed and where it can be found.
- Provide error and diagnostic information for jobs that did not successfully complete.
- Operator:
- Provide a presentation of the state of all the jobs in the print system.
- Provide the ability to identify the user that submitted the print job.
- Provide the ability to identify the resources required by each job.
- Provide the ability to define which physical printers are candidates for the print job.
- Provide some idea of how long each job will take. However, exact estimates of time to process a job is not being attempted. Instead, objects are included that allow the operator to be able to make gross estimates.
- Capacity Planner:
- Provide the ability to determine printer utilization as a function of time.
- Provide the ability to determine how long jobs wait before starting to print.
- Accountant:
- Provide information to allow the creation of a record of resources consumed and printer usage data for charging users or groups for resources consumed.
- Provide information to allow the prediction of consumable usage and resource need.
The MIB supports printers that can hold more than one job at a time, but it's still usable for low-end printers that only hold a single job at a time 🍓. In particular, the MIB supports the needs of Windows and other PC environments. It manages low-end direct-connect (serial or parallel) and networked devices without unnecessary overhead or complexity, and it also provides for higher-end systems and devices 💜.
1.2 Types of Job Monitoring Applications
the Job Monitoring MIB is designed for the following types of monitoring applications 👀:
- Monitor a single job, starting when the job is submitted and ending a defined period after the job completes. The Job Submission ID table provides the map to find the specific job to be monitored 🎯.
- Monitor all 'active' jobs in a queue, which this specification generalizes to a "job set". End users may use such a program when selecting a least busy printer, so the MIB is designed for such a program to start up quickly and find the information it needs without having to read all (completed) jobs in order to find the active jobs 🏃♀️. System operators may also use such a program. In that case it would be running for a long period of time and may also be interested in the jobs that have completed. Finally, such a program may be used to provide an enhanced console and logging capability 📋.
- Collect resource usage for accounting or system utilization purposes by copying the completed job statistics to an accounting system. It is recognized that depending on accounting programs to copy MIB data during the job-retention period is somewhat unreliable, since the accounting program may not be running (or may have crashed) 😬. Such a program is also expected to keep a shadow copy of the entire Job Attribute table, including completed, canceled, and aborted jobs, which the program updates on each polling cycle 🪞. Such a program polls at the rate of the persistence of the Attribute table. The design is not optimized to help such an application determine which jobs are completed, canceled, or aborted. Instead, the application SHOULD query each job that the application's shadow copy shows was not complete, canceled, or aborted at the previous poll cycle, to see if it is now complete or canceled, plus any new jobs that have been submitted 💖.
The MIB provides a set of objects that represent a compatible subset of job and document attributes of the ISO DPA standard [iso-dpa] and the Internet Printing Protocol (IPP) [ipp-model]. This keeps coherence between these two protocols and the information shown to end users and system operators by monitoring applications 🌷. However, the Job Monitoring MIB is intended to be used with printers that implement other job submitting and management protocols, such as IEEE 1284.1 (TIPSI) [tipsi], as well as with ones that do implement ISO DPA. Thus the Job Monitoring MIB does not require implementation of either the ISO DPA or IPP protocols 🫧.
The MIB is designed so that an additional MIB(s) can be specified in the future for monitoring multi-function (scan, FAX, copy) jobs as an augmentation to this MIB 🎀✨.
2. Terminology and Job Model ✨
okay so this section is the glossary bestie, and it's giving alphabetical order 💅 we're defining every term we use in this spec and how jobs work in general 🎀
NOTE: existing systems use conflicting terms 😭 so these terms come from the ISO 10175 Document Printing Application (DPA) standard [iso-dpa]. for example, PostScript systems call a job a session and a document a job. in this spec it's the other way around, so keep that in mind 🙈
Accounting Application: the SNMP management application that copies job information somewhere more permanent, so another application can do accounting on the data for Accountants, Asset Managers, and Capacity Planners 🧾
Agent: the network entity that takes SNMP requests from a monitor or accounting application. it gives access to the instrumentation for managing jobs, modeled by the management objects in the Job Monitoring MIB module, for a server or a device 🔌
Attribute: a name-value pair that specifies a job or document instruction, a status, or a condition of a job or document that's been submitted to a server or device. a particular attribute NEED NOT be present in each job instance 🫶 attributes only show up in a job instance when there's a need to express the value, which happens when (1) the client supplied a value in the job submission protocol, (2) the document data had an embedded attribute, or (3) the server or device supplied a default value. an agent MAY represent an attribute as an entry (row) in the Attribute table in this MIB, where entries are only present when necessary. attributes are identified in this MIB by an enum ✨
Client: the network entity end users use to submit jobs to spoolers, servers, or printers and other devices. this depends on the configuration and can use any job submission protocol, over a serial or parallel port to a directly-connected device, or over the network to a networked device 💌
Device: a hardware entity that (1) interfaces with humans, like something that makes marks on paper or scans marks on paper to make an electronic copy, (2) accesses digital media, like CD-ROMs, or (3) interfaces electronically with another device, like something that sends FAX data to another FAX device 🖨️
Document: a sub-section within a job that contains print data and document instructions that apply only to that document 📄
Document Instruction: an instruction that says how to process the document. document instructions MAY be passed in the job submission protocol separately from the actual document data, MAY be embedded in the document data, or MAY be a combo, depending on the job submission protocol and implementation 🎨
End User: a user who uses a client to submit a print job. see "user" 🙋♀️
Impression: for a print job, an impression is the passage of an entire side of a sheet past the marker. it counts whether or not any marks get made, and no matter how many passes that side makes past the marker. so a four pass color process counts as a single impression, and so does highlight color 🌈 impression counters count all kinds: monochrome, highlight color, and full process color. full color counters only count full color impressions, and high light color counters only count high light color impressions 🎀
One-sided processing involves one impression per sheet. two-sided processing involves two impressions per sheet. if a two-sided document has an odd number of pages, the last sheet still counts as two impressions, if that sheet makes two passes through the marker, or if the marker marks both sides of the sheet in a single pass 🧠 two-up printing puts two logical pages on one side of a sheet, so it's still a single impression. see "page" and "sheet" ✨
NOTE: since impressions include blank sides, it's suggested that accounting application implementers consider charging for sheets instead of impressions 💅 they could even use the value of the sides attribute to pick different charges for one-sided versus two-sided printing, since some users may think impressions don't include blank sides 🙈
Internal Collation: making the sheets for each document copy inside the printing device, by making multiple passes over either the source or an intermediate representation of the document 🧚
Job: a unit of work whose results are expected together, without unrelated results getting mixed in 🫧 a job contains one or more documents 💖
Job Accounting: the activity of a management application accessing the MIB and recording what happens to the job during and after it's processed 🧾
Job Instruction: an instruction that says how, when, or where the job is to be processed. job instructions MAY be passed in the job submission protocol, MAY be embedded in the document data, or MAY be a combination, depending on the job submission protocol and implementation 🌸
Job Monitoring (using SNMP): the activity of a management application accessing the MIB, where it (1) identifies jobs in the job tables that the server, printer, or other devices are processing, and (2) displays information to the user about how the job is going 👀
Job Monitoring Application: the SNMP management application that End Users and System Operators use to monitor jobs using SNMP. a monitor MAY be a separate application, or MAY be part of the client that also submits jobs. see "monitor" 🦋
Job Set: a group of jobs that are queued and scheduled together, according to a specified scheduling algorithm, for a specified device or set of devices 📚 for implementations that embed the SNMP agent in the device, the MIB job set normally represents all the jobs known to the device, so the implementation only implements a single job set. if the SNMP agent is in a server that controls one or more devices, each MIB job set represents a job queue for (1) a specific device or (2) a set of devices, if the server uses a single queue to load balance between several devices 🎀 each job set is disjoint, so no job SHALL be represented in more than one MIB job set 🚫
Monitor: short for Job Monitoring Application 💜
Page: a logical division of the original source document 📖 number up is putting more than one page on a single side of a sheet. see "impression", "sheet", and "two-up" 🌈
Proxy: an agent that acts as a concentrator for one or more other agents. it accepts SNMP operations on behalf of those other agents, forwards them on, gathers their responses, and returns them to the original requesting monitor 🔁
Queuing: the act of a device or server ordering (queuing) the jobs so they can be scheduled for processing 🎟️
Printer: a device that puts marks on media 🖨️✨
Server: a network entity that accepts jobs from clients and then submits them to printers and other devices. those can be directly connected to the server via a serial or parallel port, or be on the network. a server MAY be a printer supervisor control program, or a print spooler 🧑💻
Sheet: a single instance of a medium, whether it's printed on one side or both 🍓 see "impression" and "page" 🧚♀️
SNMP Information Object: a name-value pair that specifies an action, a status, or a condition in an SNMP MIB. objects are identified in SNMP by an OBJECT IDENTIFIER 🔖
Spooler: a server that accepts jobs, spools the data, and decides when and on which printer the job gets printed. a spooler is a client to a printer or a printer supervisor, depending on the implementation 🧃
Spooling: the act of a device or server of (1) accepting jobs and (2) writing the job's attributes and document data onto secondary storage 💾
Stacked: when a media sheet is placed in an output bin of a device 📥
Supervisor: a server that contains a control program that controls a printer or other device. a supervisor is a client to the printer or other device 👑
System Operator: a user who uses a monitor to watch the system and does the tasks that keep it running 🛠️
System Administrator: a user who specifies policy for the system 📋
Two-up: the placement of two pages on one side of a sheet, so that each side or impression counts as two pages. see "page" and "sheet" ✌️
User: a person who uses a client or a monitor. see "end user" 🫶
2.1 System Configurations for the Job Monitoring MIB
This section lists the three configurations the Job Monitoring MIB is meant to be used in. To keep the pictures simple, the devices are shown as printers. see section 1.1, "Types of Information in the MIB" 🦋
The diagram in the Printer MIB [print-mib] called "One Printer's View of the Network" is assumed for this MIB too. pls look at that diagram to help you understand the system configurations below 🧠✨
2.1.1 Configuration 1 - client-printer
In client-printer configuration 1, the client(s) submit jobs directly to the printer, either through a direct connect or over a network connection 🖨️💕
The job submitting client and/or monitoring application monitors jobs by talking directly to an agent that's part of the printer. the agent in the printer SHALL keep the job in the Job Monitoring MIB as long as the job is in the printer, plus a defined time period after the job enters the completed state. that way, accounting programs can copy out the accounting data from the Job Monitoring MIB 🧾🔥
all end-user ######## SNMP query
+-------+ +--------+ ---- job submission
|monitor| | client |
+---#---+ +--#--+--+
# # |
# ############ |
# # |
+==+===#=#=+==+ |
| | agent | | |
| +-------+ | |
| PRINTER <--------+
| | Print Job Delivery Channel
| |
+=============+Figure 2-1 - Configuration 1 - client-printer - agent in the printer 🎀
The Job Monitoring MIB is designed to support these relationships (not shown in Figure 2-1) 💅:
- Multiple clients MAY submit jobs to a printer.
- Multiple clients MAY monitor a printer.
- Multiple monitors MAY monitor a printer.
- A client MAY submit jobs to multiple printers.
- A monitor MAY monitor multiple printers.
2.1.2 Configuration 2 - client-server-printer - agent in the server 🧚
okay so in configuration 2, the client(s) send their jobs to an intermediate server over some network connection, not straight to the printer 🖨️ bestie. configuration 2 is included, but the design center for this MIB is configurations 1 and 3 💅
the job-submitting client and/or monitoring application keep tabs on jobs by talking directly to:
A Job Monitoring MIB agent that is part of the server (or a front for the server)
there is no SNMP Job Monitoring MIB agent in the printer in configuration 2, at least not one that the client or monitor know about 👀 in this setup the agent SHALL return the current values of the objects in the Job Monitoring MIB for jobs the server keeps AND for jobs the server has submitted to the printer ✨ the Job Monitoring MIB agent gets the info it needs from the printer by a method that is beyond the scope of this document 🙈 and the agent in the server SHALL keep the job in the Job Monitoring MIB as long as the job is in the printer, plus a defined time period after the job enters the completed state so accounting programs can copy out the accounting data 🧾 that's the aftercare era 💖
all end-user
+-------+ +----------+
|monitor| | client | ######## SNMP query
+---+---# +---#----+-+ **** non-SNMP cntrl
# # | ---- job submission
# # |
# # |
#=====#=+==v==+
| agent | |
+-------+ |
| server |
+----+-----+--+
control * |
********** |
* |
+========v====+ |
| | |
| | |
| PRINTER <---------+
| | Print Job Delivery Channel
| |
+=============+Figure 2-2 - Configuration 2 - client-server-printer - agent in the server 🌸
the Job Monitoring MIB is designed to support these relationships (not shown in Figure 2-2) 🦋
- Multiple clients MAY submit jobs to a server.
- Multiple clients MAY monitor a server.
- Multiple monitors MAY monitor a server.
- A client MAY submit jobs to multiple servers.
- A monitor MAY monitor multiple servers.
- Multiple servers MAY submit jobs to a printer.
- Multiple servers MAY control a printer.
2.1.3 Configuration 3 - client-server-printer - client monitors printer agent and server 🎀
okay configuration 3 is giving "same vibe, different plot" 💜 the client(s) once again send jobs to an intermediate server over a network connection, not directly to the printer, and that server does NOT have a Job Monitoring MIB agent in it 🙅♀️
the job-submitting client and/or monitoring application keep tabs on jobs by talking directly to:
- The server using some undefined protocol to monitor jobs in the server (the one that does not contain the Job Monitoring MIB) AND
- A Job Monitoring MIB agent that is part of the printer, to monitor jobs after the server passes them along to the printer.
in these setups, the server deletes its copy of the job after submitting it to the printer, usually almost immediately (before the job does much processing, if any) 🫨 ngl that's bold
in configuration 3, the agent (in the printer) SHALL keep the values of the objects in the Job Monitoring MIB that the agent implements updated for a job that the server has submitted to the printer 💅 the agent SHALL get info about the jobs submitted to the printer from the server (either in the job submission protocol, in the document data, or by direct query of the server) so it can fill in some of the objects in the Job Monitoring MIB in the printer 🔍 and the agent in the printer SHALL keep the job in the Job Monitoring MIB as long as the job is in the Printer, and longer so it can implement the completed state where monitoring programs can copy out the accounting data 📊 iconic tbh
all end-user
+-------+ +----------+
|monitor| | client | ######## SNMP query
+---+---* +---*----+-+ **** non-SNMP query
# * * | ---- job submission
# * * |
# * * |
# *=====v====v==+
# | |
# | server |
# | |
# +----#-----+--+
# optional# |
# ########## |
# # |
+==+=v===v=+==+ |
| | agent | | |
| +-------+ | |
| PRINTER <---------+
| | Print Job Delivery Channel
| |
+=============+Figure 2-3 - Configuration 3 - client-server-printer - client monitors printer agent and server 🌈
the Job Monitoring MIB is designed to support these relationships (not shown in Figure 2-3) 💖
- Multiple clients MAY submit jobs to a server.
- Multiple clients MAY monitor a server.
- Multiple monitors MAY monitor a server.
- A client MAY submit jobs to multiple servers.
- A monitor MAY monitor multiple servers.
- Multiple servers MAY submit jobs to a printer.
- Multiple servers MAY control a printer.
3 Managed Object Usage ✨
this section is all about how the objects in the MIB get used 🧚
3.1 Conformance Considerations 💅
so, for interoperability between job monitoring applications and job monitoring agents, this spec includes conformance requirements for BOTH the monitoring applications and the agents 🫶
3.1.1 Conformance Terminology 📚
this spec uses the verbs "SHALL", "SHOULD", "MAY", and "NEED NOT" to set conformance requirements according to RFC 2119 [RFC2119], and here's how they hit 🔥
- "SHALL": indicates an action that the subject of the sentence must implement in order to claim conformance to this specification
- "MAY": indicates an action that the subject of the sentence does not have to implement in order to claim conformance to this specification, in other words that action is an implementation option 🌸
- "NEED NOT": indicates an action that the subject of the sentence does not have to implement in order to claim conformance to this specification. the verb "NEED NOT" is used instead of "may not", since "may not" sounds like a prohibition 🙈 lowkey smart wording
- "SHOULD": indicates an action that is recommended for the subject of the sentence to implement, but is not required, in order to claim conformance to this specification 🦋
3.1.2 Agent Conformance Requirements 🤖
okay so a conforming agent:
- SHALL implement all MANDATORY groups in this specification.
- SHALL implement any attributes if (1) the server or device supports the functionality represented by the attribute and (2) the information is available to the agent 💖
- SHOULD implement both forms of an attribute if it implements an attribute that permits a choice of INTEGER and OCTET STRING forms, since implementing both forms may help management applications by giving them a choice of representations, since the representation are equivalent. see the JmAttributeTypeTC textual-convention 🎀
NOTE - This MIB, like the Printer MIB, is written following the subset of SMIv2 that can be supported by SMIv1 and SNMPv1 implementations. 🧚
3.1.2.1 MIB II System Group objects 🌈
the Job Monitoring MIB agent SHALL implement all objects in the System Group of MIB-II [mib-II], whether the Printer MIB [print-mib] is implemented or not 💅
3.1.2.2 MIB II Interface Group objects 🍓
the Job Monitoring MIB agent SHALL implement all objects in the Interfaces Group of MIB-II [mib-II], whether the Printer MIB [print-mib] is implemented or not 🫶
3.1.2.3 Printer MIB objects 🖨️
if the agent is providing access to a device that is a printer, the agent SHALL implement all of the MANDATORY objects in the Printer MIB [print-mib] AND all the objects in other MIBs that conformance to the Printer MIB requires, such as the Host Resources MIB [hr-mib]. if the agent is providing access to a server that controls one or more direct-connect or networked printers, the agent NEED NOT implement the Printer MIB and NEED NOT implement the Host Resources MIB 🙃 no pressure, bestie
3.1.3 Job Monitoring Application Conformance Requirements 📱
okay so a conforming job monitoring application:
- SHALL accept the full syntactic range for all objects in all MANDATORY groups and all MANDATORY attributes that are required to be implemented by an agent according to Section 3.1.2, and SHALL either present them to the user or ignore them 👀
- SHALL accept the full syntactic range for all attributes, including enum and bit values specified in this specification and additional ones that may be registered with the PWG, and SHALL either present them to the user or ignore them. in particular, a conforming job monitoring application SHALL not malfunction when receiving any standard or registered enum or bit values. see Section 3.7 entitled "IANA and PWG Registration Considerations" 🧠 the no-crash energy is real
- SHALL NOT fail when operating with agents that materialize attributes after the job has been submitted, as opposed to when the job is submitted 🙅♀️ we do not do drama here
- SHALL, if it supports a time attribute, accept either form of the time attribute, since agents are free to implement either time form ⏰ the flexibility is literally iconic 👑
3.2 The Job Tables and the Oldest Active and Newest Active Indexes ✨
okay bestie, the jmJobTable and jmAttributeTable are where all the juicy info about each job lives 💖 Each job gets its own row, and the first two indexes are:
jmGeneralJobSetIndex- which job setjmJobIndex- which job in the job set
Now, monitoring apps need to find the active jobs (pending, processing, or processingStopped) FAST, so the MIB gives us two extra indexes 🔥
jmGeneralOldestActiveJobIndex- the index of the active job that has been in the tables the longest.jmGeneralNewestActiveJobIndex- the index of the active job that has been most recently added to the tables.
The agent SHALL assign the next incremental value of jmJobIndex to the job, when a new job is accepted by the server or device to which the agent is providing access. If the incremented value of jmJobIndex would exceed the implementation-defined maximum value for jmJobIndex, the agent SHALL 'wrap' back to 1. An agent uses the resulting value of jmJobIndex for storing information in the jmJobTable and the jmAttributeTable about the job.
It's recommended that the largest value for jmJobIndex be much larger than the maximum number of jobs the implementation can hold at one time 🌸 That way, a jmJobIndex doesn't get reused too soon while clients are still holding onto the 'stale' value for an older job. Iykyk 🙈
It's recommended that agents providing access to servers or devices that already allocate job identifiers as integers use that same integer value for the jmJobIndex. Then management apps using this MIB and apps using other protocols will see the same job identifiers for the same jobs 🦋 Agents providing access to systems with a job identifier of 0 SHALL map the job identifier value 0 to a jmJobIndex value that is one higher than the highest job identifier value any job can have on that system. Then only job 0 will have a different job-identifier value than its jmJobIndex value.
NOTE - If a server or device accepts jobs using multiple job submission protocols, it may be difficult for the agent to meet the recommendation to use the job-identifier values that the server or device assigns as the jmJobIndex value, unless the server/device assigns job-identifiers for each of its job submission protocols from the same job-identifier number space.
Every time a new job is accepted by the server or device the agent is providing access to AND that job is to be 'active' (pending, processing, or processingStopped, but not pendingHeld), the agent SHALL copy the value of the job's jmJobIndex to the jmGeneralNewestActiveJobIndex object 💅 If the new job is to be 'inactive' (pendingHeld state), the agent SHALL not change the value of the jmGeneralNewestActiveJobIndex object (though the agent SHALL assign the next incremental jmJobIndex value to the job).
When a job goes from one of the 'active' job states (pending, processing, processingStopped) to one of the 'inactive' job states (pendingHeld, completed, canceled, or aborted), and its jmJobIndex value matches the jmGeneralOldestActiveJobIndex object, the agent SHALL advance (or wrap) the value to the next oldest 'active' job, if any. See the JmJobStateTC textual-convention for a definition of the job states.
Whenever a job goes from one of the 'inactive' job states to one of the 'active' job states (from pendingHeld to pending or processing), the agent SHALL update the value of either the jmGeneralOldestActiveJobIndex or the jmGeneralNewestActiveJobIndex objects, or both, if the job's jmJobIndex value is outside the range between jmGeneralOldestActiveJobIndex and jmGeneralNewestActiveJobIndex 🦄
When all jobs become 'inactive', i.e., enter the pendingHeld, completed, canceled, or aborted states, the agent SHALL set the value of both the jmGeneralOldestActiveJobIndex and jmGeneralNewestActiveJobIndex objects to 0 💀
NOTE - Apps that want to efficiently access all of the active jobs MAY use thejmGeneralOldestActiveJobIndexvalue to start with the oldest active job and keep going until they reach the index value equal tojmGeneralNewestActiveJobIndex, skipping over any pendingHeld, completed, canceled, or aborted jobs that might be in the way. Main character energy 👑
If an app detects that jmGeneralNewestActiveJobIndex is smaller than jmGeneralOldestActiveJobIndex, the job index has wrapped. In this case, the app SHALL reset the index to 1 when the end of the table is reached and continue the GetNext operations to find the rest of the active jobs 🧚
NOTE - Apps detect the end of thejmAttributeTabletable when the OID returned by the GetNext operation is an OID in a different MIB. There is no object in this MIB that specifies the maximum value for thejmJobIndexsupported by the implementation.
When the server or device is power-cycled, the agent SHALL remember the next jmJobIndex value to be assigned, so that new jobs are not assigned the same jmJobIndex as recent jobs before the power cycle 🍓
3.3 The Attribute Mechanism and the Attribute Table(s) 🎀
Attributes are kind of like information objects, except attributes are identified by an enum instead of an OID, so new attributes can be registered without needing a brand new MIB 🌈 Also, an implementation that doesn't have the functionality an attribute represents can just leave the attribute out entirely, instead of returning some special value. The agent is free to materialize an attribute in the jmAttributeTable as soon as it knows the value of that attribute.
The agent materializes job attributes in a four-indexed jmAttributeTable:
jmGeneralJobSetIndex- which job setjmJobIndex- which job in the job setjmAttributeTypeIndex- which attributejmAttributeInstanceIndex- which attribute instance, for those attributes that can have multiple values per job.
Some attributes are info about a job, like a file name, a document name, a submission time, or a completion time 📝 Other attributes are resources the job needs, like a medium or a colorant, to get processed before it starts, OR they show how much of a resource got used during and after processing, like pages completed or impressions completed. If both a required and a consumed value of a resource are needed, this spec assigns two separate attribute enums in the textual convention ✨
NOTE - The table of contents lists all the attributes in order. This order is the order of enum assignments, which is also the order the SNMP GetNext operation returns attributes. Most attributes apply to all three configurations covered by this MIB specification (see section 2.1 entitled "System Configurations for the Job Monitoring MIB"). Those attributes that apply to a particular configuration are indicated as 'Configuration n:' and SHALL NOT be used with other configurations 🙅♀️
3.3.1 Conformance of Attribute Implementation
An agent SHALL implement any attribute if (1) the server or device supports the functionality the attribute represents and (2) the information is available to the agent. The agent MAY create the attribute row in the jmAttributeTable when the information is available, or MAY create the row earlier with the designated 'unknown' value appropriate for that attribute. See the next section 💖
If the server or device does not implement or does not provide access to the information about an attribute, the agent SHOULD NOT create the corresponding row in the jmAttributeTable 🙈
3.3.2 Useful, 'Unknown', and 'Other' Values for Objects and Attributes
Some attributes have a 'useful' Integer32 value, some have a 'useful' OCTET STRING value, some MAY have either or both depending on the implementation, and some MUST have both. See the JmAttributeTypeTC textual convention for the spec of each attribute 🍓
SNMP requires that if an object can't be implemented because its values can't be accessed, then a compliant agent SHALL return an SNMP error in SNMPv1 or an exception value in SNMPv2. HOWEVER, this MIB was designed so that 'all' objects can and SHALL be implemented by an agent, so neither the SNMPv1 error nor the SNMPv2 exception value SHALL be generated by the agent 😭 This MIB was also designed so that when an agent materializes an attribute, the agent SHALL materialize a row consisting of both the jmAttributeValueAsInteger and jmAttributeValueAsOctets objects.
In general, values for objects and attributes were chosen so that a management app can tell whether a 'useful', 'unknown', or 'other' value is available 🔍 When a useful value isn't available for an object, the agent SHALL return a zero-length string for octet strings, the value unknown(2) for enums, a 0 value for an object that represents an index in another table, and a value of -2 for counting integers.
Since each attribute is represented by a row consisting of both the jmAttributeValueAsInteger and jmAttributeValueAsOctets MANDATORY objects, SNMP requires that the agent SHALL always create an attribute row with both objects specified. However, for most attributes, the agent SHALL return a "useful" value for one of the objects and SHALL return the 'other' value for the other object. For integer-only attributes, the agent SHALL always return a zero-length string value for the jmAttributeValueAsOctets object. For octet-string-only attributes, the agent SHALL always return a -1 value for the jmAttributeValueAsInteger object. 🌸
3.3.3 Index Value Attributes
A bunch of attributes are indexes in other tables, and those attribute names end with the word 'Index' 🧚♀️ If the agent hasn't (yet) assigned an index value for a particular index attribute for a job, the agent SHALL either: (1) return the value 0 or (2) not add this attribute to the jmAttributeTable until the index value is assigned. To keep things brief, the semantics for 0 are specified once here and not repeated for each index attribute specification, and a DEFVAL of 0 is implied, even though the DEFVAL for jmAttributeValueAsInteger is -2 💅✨
3.3.4 Data Sub-types and Attribute Naming Conventions
okay so lots of attributes get sub-typed so they can be more specific than Integer32 or OCTET STRING 💅 The sub-type of each attribute is shown on the first line(s) of its description ✨ Some attributes have several sub-type representations. When an attribute has BOTH an Integer32 sub-type AND an OCTET STRING sub-type, it can live in a single row of the jmAttributeTable 🎀 In that case the sub-type name is not tacked onto the end of the attribute name, like documentFormat(38), which is both an enum and/or a name 🦋 When the sub-types can't fit in one row, each representation counts as its own separate attribute with its own name and enum value 🌈 For those, the sub-type name goes on the end: Name, Index, DateAndTime, TimeStamp, etc. For example, documentFormatIndex(37) is an index 💜
Heads up from the Table of Contents 📋 It lists each attribute's sub-type and/or sub-types, using the textual-convention name when one is defined. These are the abbreviations it uses:
'Int32(-2..)' Integer32 (-2..2147483647)
'Int32(0..)' Integer32 (0..2147483647)
'Int32(1..)' Integer32 (1..2147483647)
'Int32(m..n)' For all other Integer ranges, the lower
and upper bound of the range is
indicated.
'UTF8String63' JmUTF8StringTC (SIZE(0..63))
'JobString63' JmJobStringTC (SIZE(0..63))
'Octets63' OCTET STRING (SIZE(0..63))
'Octets(m..n)' For all other OCTET STRING ranges, the
exact range is indicated.3.3.5 Single-Value (Row) Versus Multi-Value (MULTI-ROW) Attributes
Most attributes only get one row per job 🌸 But a few can have multiple values per job, or even per document, and each value gets its own row in the jmAttributeTable 🫶 Unless it's marked with MULTI-ROW: in the JmAttributeTypeTC description, an agent SHALL ensure that each attribute occurs only once in the jmAttributeTable for a job. Most MULTI-ROW attributes don't allow duplicate values, so the agent SHALL ensure that each value occurs only once for a job. The agent can only allow duplicates for the job if the specification of the MULTI-ROW attribute also says "There is no restriction on the same xxx occurring in multiple rows" 👑
NOTE - Duplicates are allowed for 'extensive' MULTI-ROW attributes, such as fileName(34) or documentName(35), which are specified to be per-document attributes. They are not allowed for 'intensive' MULTI-ROW attributes, such as mediumConsumed(171) and documentFormat(38), which are specified to be per-job attributes. 🙈
3.3.6 Requested Objects and Attributes
A bunch of objects and attributes record what the job asked for 🙋 Their names end with the word 'Requested'. To keep things short, 'requested' means: (1) requested by the client (or an intervening server) in the job submission protocol, and it may also mean (2) embedded in the submitted document data, and/or (3) defaulted by the recipient device or server with the same semantics as if the requester had supplied it, depending on implementation. Also, if the job submission client supplies a value but the server/device works out a better one (through processing or other means), the agent MAY return that better value for such object and attribute ✨
3.3.7 Consumption Attributes
Some objects and attributes record consumption 🧃 Their names end with 'Completed' or 'Consumed'. If the job hasn't consumed the resource being metered yet, the agent either: (1) SHALL return the value 0 or (2) SHALL not add this attribute to the jmAttributeTable until the consumption begins. To keep it brief, the meaning of 0 is spelled out once here and not repeated for every consumption attribute. A DEFVAL of 0 is implied, even though the DEFVAL for jmAttributeValueAsInteger is -2 🌸
3.3.8 Attribute Specifications
This section specifies the job attributes 📚
In the following definitions of the attributes, each description says whether the useful value of the attribute SHALL be represented using the jmAttributeValueAsInteger or the jmAttributeValueAsOctets objects, by the initial tag: INTEGER: or OCTETS:, respectively 🦋
Some attributes give the agent implementer a choice of useful values, either an integer, an octet string representation, or both, depending on implementation. These attributes are marked with INTEGER: AND/OR OCTETS: tags 💜
A very few attributes need both objects at the same time to represent a pair of useful values (see mediumConsumed(171)). These are marked with INTEGER: AND OCTETS: tags. See the jmAttributeGroup for the descriptions of these two MANDATORY objects 🎀
NOTE - The enum assignments are grouped logically, with values assigned in groups of 20, so that additional values may be registered in the future and assigned a value that is part of their logical grouping. 🍓
Values in the range 230 to 231-1 are reserved for private or experimental usage. This range matches the one reserved in IPP. Implementers are warned that using such values may conflict with other implementations ⚠️ Implementers are encouraged to request registration of enum values following the procedures in Section 3.7.1 🌈
NOTE: No attribute name exceeds 31 characters. 💅
The standard attribute types are:
jmAttributeTypeIndex Datatype
-------------------- --------
other(1), Integer32 (-2..2147483647)
AND/OR
OCTET STRING(SIZE(0..63))
INTEGER: and/or OCTETS: An attribute that is not in the
list and/or that has not been approved and registered with
the PWG.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Job State attributes (3 - 19 decimal)
+
+ The following attributes specify the state of a job.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
jobStateReasons2(3), JmJobStateReasons2TC
INTEGER: Additional information about the job's current state
that augments the jmJobState object. See the description under
the JmJobStateReasons1TC textual-convention.
jobStateReasons3(4), JmJobStateReasons3TC
INTEGER: Additional information about the job's current state
that augments the jmJobState object. See the description under
JmJobStateReasons1TC textual-convention.
jobStateReasons4(5), JmJobStateReasons4TC
INTEGER: Additional information about the job's current state
that augments the jmJobState object. See the description under
JmJobStateReasons1TC textual-convention.
processingMessage(6), JmUTF8StringTC (SIZE(0..63))
OCTETS: MULTI-ROW: A coded character set message that is
generated by the server or device during the processing of the
job as a simple form of processing log to show progress and any
problems. The natural language of each value is specified by
the corresponding processingMessageNaturalLangTag(7) value.
NOTE - This attribute is intended for such conditions as
interpreter messages, rather than being the printable form of
the jmJobState and jmJobStateReasons1 objects and
jobStateReasons2, jobStateReasons3, and jobStateReasons4
attributes. In order to produce a localized printable form of
these job state objects/attribute, a management application
SHOULD produce a message from their enum and bit values.
NOTE - There is no job description attribute in IPP/1.0 that
corresponds to this attribute and this attribute does not
correspond to the IPP/1.0 'job-state-message' job description
attribute, which is just a printable form of the IPP 'job-state'
and 'job-state-reasons' job attributes.
There is no restriction for the same message occurring in
multiple rows.
processingMessageNaturalLangTag(7), OCTET STRING(SIZE(0..63))
OCTETS: MULTI-ROW: The natural language of the corresponding
processingMessage(6) attribute value. See section 3.6.1,
entitled 'Text generated by the server or device'.
If the agent does not know the natural language of the job
processing message, the agent SHALL either (1) return a zero
length string value for the processingMessageNaturalLangTag(7)
attribute or (2) not return the
processingMessageNaturalLangTag(7) attribute for the job.
There is no restriction for the same tag occurring in multiple
rows, since when this attribute is implemented, it SHOULD have a
value row for each corresponding processingMessage(6) attribute
value row.
jobCodedCharSet(8), CodedCharSet
INTEGER: The MIBenum identifier of the coded character set that
the agent is using to represent coded character set objects and
attributes of type 'JmJobStringTC'. These coded character set
objects and attributes are either: (1) supplied by the job
submitting client or (2) defaulted by the server or device when
omitted by the job submitting client. The agent SHALL represent
these objects and attributes in the MIB either (1) in the coded
character set as they were submitted or (2) MAY convert the
coded character set to another coded character set or encoding
scheme as identified by the jobCodedCharSet(8) attribute. See
section 3.6.2, entitled 'Text supplied by the job submitter'.
These MIBenum values are assigned by IANA [IANA-charsets] when
the coded character sets are registered. The coded character
set SHALL be one of the ones registered with IANA [IANA] and the
enum value uses the CodedCharSet textual-convention from the
Printer MIB. See the JmJobStringTC textual-convention.
If the agent does not know what coded character set was used by
the job submitting client, the agent SHALL either (1) return the
'unknown(2)' value for the jobCodedCharSet(8) attribute or (2)
not return the jobCodedCharSet(8) attribute for the job.
jobNaturalLanguageTag(9), OCTET STRING(SIZE(0..63))
OCTETS: The natural language of the job attributes supplied by
the job submitter or defaulted by the server or device for the
job, i.e., all objects and attributes represented by the '
JmJobStringTC' textual-convention, such as jobName,
mediumRequested, etc. See Section 3.6.2, entitled 'Text
supplied by the job submitter'.
If the agent does not know what natural language was used by the
job submitting client, the agent SHALL either (1) return a zero
length string value for the jobNaturalLanguageTag(9) attribute
or (2) not return jobNaturalLanguageTag(9) attribute for the
job.+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- Job Identification attributes (20 - 49 decimal) +
- The following attributes help an end user, a system
- operator, or an accounting program identify a job. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Okay, next up are the Job Identification attributes (20 to 49 decimal) 🪪✨ These are the ones that help an end user, a system operator, or an accounting program figure out which job is which. Honestly, this is the part where everyone's looking for their stuff, so it matters a lot 💅
jobURI(20), OCTET STRING(SIZE(0..63))
OCTETS: MULTI-ROW:jobURI 🔗 is the job's Universal Resource Identifier (URI) [RFC1738]. For example usage, see IPP [ipp-model].
NOTE: the agent may be able to generate this value on each SNMP Get operation from smaller values, so it doesn't have to store the entire URI. Smart! 🧠
If the URI goes over 63 octets, the agent SHALL use multiple values, with the next 63 octets coming in the second value, and so on. ✨
NOTE: IPP [ipp-model] has a 1023-octet maximum length for a URI, but the URI standard itself and HTTP/1.1 don't specify any maximum length. Fun fact for your brain 🧁
jobAccountName(21), OCTET STRING(SIZE(0..63))
OCTETS:jobAccountName 💳 is arbitrary binary information that MAY be coded character set data or encrypted data. The submitting user supplies it so accounting services can allocate or categorize charges for services, like a customer account name or number. It's giving "billing details" energy 💖
NOTE: this attribute need not be printable characters, so don't assume it's readable text 🙈
serverAssignedJobName(22), JmJobStringTC (SIZE(0..63))
OCTETS: Configuration 3 only:serverAssignedJobName 🏷️ is, for configuration 3 only, the human readable string name, number, or ID of the job as assigned by the server that submitted the job to the device the agent is providing access to with this MIB.
NOTE: this one exists so a user can find their job that a server submitted to a device, especially when the client doesn't support the jmJobSubmissionID or the server doesn't pass the jmJobSubmissionID through to the device. It's a lifesaver when things get lost in the pipeline 🫶
jobName(23), JmJobStringTC (SIZE(0..63))
OCTETS:jobName 🎀 is the human readable string name of the job, assigned by the submitting user so they can tell their different jobs apart. It doesn't need to be unique, so don't stress about that 💅
This attribute is meant for letting a user or their application set a job name that MAY be printed on a start sheet, returned in a query result, or used in notification or logging messages.
To help users find their jobs for job submission protocols that don't supply a jmJobSubmissionID, the agent SHOULD keep the jobName attribute for as long as the jmGeneralJobPersistence object says, rather than the shorter jmGeneralAttributePersistence object. Main character persistence 👑
If no jobName is specified when the job is submitted, no job name is assumed. Implementation specific defaults are allowed, though, like using the documentName or fileName attribute of the first document in the job. 🌸
Lowkey important distinction time 🧐 The jobName is for telling your own jobs apart. The jobComment is free form extra info you might want to leave yourself, like a reminder about what to do with the results, or a note that you tried a different set of input parameters in several submissions. Different vibes entirely 💜
jobServiceTypes(24), JmJobServiceTypesTC
INTEGER:jobServiceTypes 🖨️📠🔍 specifies the type(s) of service the job was submitted to, like print, fax, scan, and so on. The service type is bit encoded, with each job service type getting its own bit, so more general and arbitrary services can be created. Those can include services with more than one destination type, or ones with only a source or only a destination.
For example, a job service might scan, faxOut, and print a single job. In that case, three bits would be set in the jobServiceTypes attribute, matching the hexadecimal values 0x8 + 0x20 + 0x4, which gives you 0x2C. Math slay 🧮✨
Whether this attribute is set from a job attribute supplied by the job submission client, or set by the recipient job submission server or device, depends on the job submission protocol. This attribute SHALL be implemented if the server or device has other types in addition to or instead of printing. 🙌
One of the big purposes here is letting a requester filter out jobs they don't care about. A printer operator, for example, may only be interested in jobs that include printing 🖨️💖
jobSourceChannelIndex(25), Integer32 (0..2147483647)
INTEGER:jobSourceChannelIndex 📡 is the index of the row in the associated Printer MIB [print-mib] for the channel that's the source of the print job.
jobSourcePlatformType(26), JmJobSourcePlatformTypeTC
INTEGER:jobSourcePlatformType 💻 is the source platform type of the immediate upstream submitter that sent the job to the server (configuration 2) or device (configuration 1 and 3) that the agent is providing access to. It depends on the configuration:
- For configuration 1, it's the type of the client that submitted the job to the device.
- For configuration 2, it's the type of the client that submitted the job to the server.
- For configuration 3, it's the type of the server that submitted the job to the device.
submittingServerName(27), JmJobStringTC (SIZE(0..63))
OCTETS: For configuration 3 only:submittingServerName 🖥️ is, for configuration 3 only, the administrative name of the server that submitted the job to the device.
submittingApplicationName(28), JmJobStringTC (SIZE(0..63))
OCTETS:submittingApplicationName 📱 is the name of the client application (not the server in configuration 3) that submitted the job to the server or device.
jobOriginatingHost(29), JmJobStringTC (SIZE(0..63))
OCTETS:jobOriginatingHost 🏠 is the name of the client host (not the server host name in configuration 3) that submitted the job to the server or device.
deviceNameRequested(30), JmJobStringTC (SIZE(0..63))
OCTETS:deviceNameRequested 🎯 is the administratively defined coded character set name of the target device the submitting user asked for. For configuration 1, its value corresponds to the Printer MIB [print-mib] prtGeneralPrinterName object. For configuration 2 and 3, its value is the name of the logical or physical device the user supplied to tell the server which device(s) they wanted the job processed on.
queueNameRequested(31), JmJobStringTC (SIZE(0..63))
OCTETS:queueNameRequested 🚦 is the administratively defined coded character set name of the target queue the submitting user asked for. For configuration 1, its value corresponds to the queue in the device the agent is providing access to. For configuration 2 and 3, its value is the name of the queue the user supplied to tell the server which device(s) they wanted the job processed on.
NOTE: typically an implementation SHOULD support either the deviceNameRequested or the queueNameRequested attribute, but not both. Pick a lane 🛣️
physicalDevice(32), hrDeviceIndex
AND/OR
JmUTF8StringTC (SIZE(0..63))
INTEGER: MULTI-ROW:physicalDevice 🧩 has two possible forms. The first is an INTEGER with MULTI-ROW, which is the index of the physical device MIB instance requested or used, such as the Printer MIB [print-mib]. This value is an hrDeviceIndex value, so see the Host Resources MIB [hr-mib].
AND/OR
OCTETS: MULTI-ROW:The second form is an OCTETS value with MULTI-ROW, which is the name of the physical device the job is assigned to. Pick whichever one fits your setup 💖
numberOfDocuments(33), Integer32 (-2..2147483647)
INTEGER:numberOfDocuments 📚 is the number of documents in this job.
The agent SHOULD return this attribute if the job has more than one document. 🙌
fileName(34), JmJobStringTC (SIZE(0..63))
OCTETS: MULTI-ROW:fileName 📄 is the coded character set file name or URI [URI-spec] of the document.
There's no restriction on the same file name showing up in multiple rows, so no drama if it repeats 🌈
documentName(35), JmJobStringTC (SIZE(0..63))
OCTETS: MULTI-ROW:documentName 📝 is the coded character set name of the document.
Same deal here: there's no restriction on the same document name appearing in multiple rows 💅
jobComment(36), JmJobStringTC (SIZE(0..63))
OCTETS:jobComment 💬 is an arbitrary human-readable coded character text string that the submitting user or the job submitting application program supplies for any purpose. A user might note what they're going to do with the printed output, or the application might say how the document was produced. Very diary-coded energy 📔
The jobComment attribute is not intended to be a name. For that, check out jobName.
documentFormatIndex(37), Integer32 (0..2147483647)
INTEGER: MULTI-ROW:documentFormatIndex 🗂️ is the index in the prtInterpreterTable in the Printer MIB [print-mib] of the page description language (PDL) or control language interpreter that this job requires or uses. A document or a job MAY use more than one PDL or control language. 🤹
NOTE: as with all intensive attributes where multiple rows are allowed, there SHALL be only one distinct row for each distinct interpreter. There SHALL be no duplicates. No copies allowed 🚫
NOTE: this attribute type is meant to be used with an agent that implements the Printer MIB. It SHALL not be used if the agent doesn't implement the Printer MIB. Such an agent SHALL use the documentFormat attribute instead. Know your setup! 🧠
documentFormat(38), PrtInterpreterLangFamilyTC
AND/OR
OCTET STRING(SIZE(0..63))
INTEGER: MULTI-ROW:documentFormat 🎨 has two possible forms too. The INTEGER version with MULTI-ROW is the interpreter language family corresponding to the Printer MIB [print-mib] prtInterpreterLangFamily object that this job requires or uses. A document or a job MAY use more than one PDL or control language.
AND/OR
OCTETS: MULTI-ROW:The OCTETS version with MULTI-ROW is the document format registered as a media type [iana-media-types], meaning the name of the MIME content-type/subtype. Some examples are 'application/postscript', 'application/vnd.hp-PCL', 'application/pdf', 'text/plain' (US-ASCII SHALL be assumed), 'text/plain; charset=iso-8859-1', and 'application/octet-stream'. The IPP 'document-format' job attribute uses these same values with the same semantics. For more examples and explanation, see the IPP [ipp-model] 'mimeMediaType' attribute syntax and the document-format attribute. MIME types all the way down 🌸📄
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Job Parameter attributes (50 - 67 decimal)
+
+ The following attributes represent input parameters
+ supplied by the submitting client in the job submission
+ protocol.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Now we're into the Job Parameter attributes (50 to 67 decimal) 🎛️💜 These are the input parameters the submitting client sends over in the job submission protocol, so they're basically the job's settings.
jobPriority(50), Integer32 (-2..100)
INTEGER:jobPriority ⭐ is the priority for scheduling the job. Servers and devices that use a priority-based scheduling algorithm use it to decide what goes first. Bestie, it's giving VIP queue 👑
The higher the value, the higher the priority 💅 A 1 is the lowest possible priority, aka a job that a priority-based scheduling algorithm SHALL pass over in favor of higher priority jobs 😭 A 100 is the highest possible priority 👑. Priority is expected to be evenly or 'normally' distributed across that range 🌈, and how vendor-defined priorities map onto the range is implementation-specific 🧚. -2 means unknown 🙈.
jobProcessAfterDateAndTime(51), DateAndTime (SNMPv2-TC)
OCTETS:This is the calendar date and time of day after which the job SHALL become a candidate to be scheduled for processing 📅. If that value is in the future, the server SHALL set the job's jmJobState object to pendingHeld and add the jobProcessAfterSpecified bit value to the job's jmJobStateReasons1 object 🙈. Once the date and time arrives, the server SHALL remove the jobProcessAfterSpecified bit value from jmJobStateReasons1 and, if no other reasons remain, SHALL change the job's jmJobState object to pending ✨.
jobHold(52), JmBooleanTC
INTEGER:If the value is 'true(4)', a client has explicitly asked for the job to be held until it's explicitly released 🧊. Until a client explicitly releases it, the job SHALL be in the pendingHeld state with the jobHoldSpecified value in the jmJobStateReasons1 attribute 🫶.
jobHoldUntil(53), JmJobStringTC (SIZE(0..63))
OCTETS:This is a named time period during which the job SHALL become a candidate for processing, like 'evening', 'night', 'weekend', 'second-shift', 'third-shift', and so on 🌙. The supported values are configured by the system administrator. For the standard keyword values, check out IPP [ipp-model] 📚. Until that time period arrives, the job SHALL be in the pendingHeld state with the jobHoldUntilSpecified value in the jmJobStateReasons1 object 💤. The value 'no-hold' SHALL indicate explicitly that no time period has been specified, and the absence of this attribute SHALL indicate implicitly that no time period has been specified 🍓.
outputBin(54), Integer32 (0..2147483647)
AND/OR
JmJobStringTC (SIZE(0..63))
INTEGER: MULTI-ROW:
AND/OR
OCTETS: MULTI-ROW:As an integer, this is the output subunit index in the Printer MIB [print-mib] 🖨️. As an octet string, it's the name or number (written as ASCII digits) of the output bin where all or part of the job gets placed 🎀. It's a both-ways situation, so you get your pick of format 💖.
sides(55), Integer32 (-2..2)
INTEGER: MULTI-ROW:This is the number of sides, '1' or '2', that any document in this job requires or uses 📄.
finishing(56), JmFinishingTC
INTEGER: MULTI-ROW:This is the type of finishing that any document in this job requires or uses ✂️.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Image Quality attributes (requested and consumed) (70 - 87)
+
+ For devices that can vary the image quality.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++printQualityRequested(70), JmPrintQualityTC
INTEGER: MULTI-ROW:The print quality selection requested for a document in the job, for printers that allow quality differentiation 🎨.
printQualityUsed(71), JmPrintQualityTC
INTEGER: MULTI-ROW:The print quality selection actually used by a document in the job, for printers that allow quality differentiation ✨.
printerResolutionRequested(72), JmPrinterResolutionTC
OCTETS: MULTI-ROW:The printer resolution requested for a document in the job, for printers that support resolution selection 🔍.
printerResolutionUsed(73), JmPrinterResolutionTC
OCTETS: MULTI-ROW:The printer resolution actually used by a document in the job, for printers that support resolution selection 🫧.
tonerEcomonyRequested(74), JmTonerEconomyTC
INTEGER: MULTI-ROW:The toner economy selection requested for documents in the job, for printers that allow toner economy differentiation 💜.
tonerEcomonyUsed(75), JmTonerEconomyTC
INTEGER: MULTI-ROW:The toner economy selection actually used by documents in the job, for printers that allow toner economy differentiation 🌸.
tonerDensityRequested(76) Integer32 (-2..100)
INTEGER: MULTI-ROW:The toner density requested for a document in this job, for devices that can vary toner density levels. Level 1 is the lowest density and level 100 is the highest. Devices with a smaller range, SHALL map the 1-100 range evenly onto the implemented range 🎀.
tonerDensityUsed(77), Integer32 (-2..100)
INTEGER: MULTI-ROW:The toner density used by documents in this job, for devices that can vary toner density levels. Level 1 is the lowest density and level 100 is the highest. Devices with a smaller range, SHALL map the 1-100 range evenly onto the implemented range 🦋.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Job Progress attributes (requested and consumed) (90-109)
+
+ Pairs of these attributes can be used by monitoring
+ applications to show an indication of relative progress
+ to users. See section 3.4, entitled:
+ 'Monitoring Job Progress'.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++jobCopiesRequested(90), Integer32 (-2..2147483647)
INTEGER:The number of copies of the entire job that are to be produced 🍰.
jobCopiesCompleted(91), Integer32 (-2..2147483647)
INTEGER:The number of copies of the entire job that have been completed so far 🎉.
documentCopiesRequested(92), Integer32 (-2..2147483647)
INTEGER:The total count of document copies requested for the job as a whole. If there are documents A, B, and C, and document B is specified to produce 4 copies, the number of document copies requested is 6 for the job.
This attribute SHALL be used only when a job has multiple documents. The jobCopiesRequested attribute SHALL be used when the job has only one document 🧩.
documentCopiesCompleted(93), Integer32 (-2..2147483647)
INTEGER:The total count of document copies completed so far for the job as a whole. If there are documents A, B, and C, and document B is specified to produce 4 copies, the number of document copies starts at 0 and runs up to 6 as the job processes 📈.
This attribute SHALL be used only when a job has multiple documents. The jobCopiesCompleted attribute SHALL be used when the job has only one document 🌈.
jobKOctetsTransferred(94), Integer32 (-2..2147483647)
INTEGER:The number of K (1024) octets transferred to the server or device that the agent is providing access to. This count doesn't depend on how many copies of the job or documents will be produced. It's only a measure of the bytes transferred to the server or device 📦.
The agent SHALL round the actual number of octets transferred up to the next higher K. So 0 octets SHALL be represented as 0, 1-1024 octets SHALL be represented as 1, 1025-2048 SHALL be 2, etc. When the job completes, the values of the jmJobKOctetsPerCopyRequested object and the jobKOctetsTransferred attribute SHALL be equal 🧮.
NOTE - ThejobKOctetsTransferredcan be used with thejmJobKOctetsPerCopyRequestedobject to get a relative sense of job progress for agents that don't implement thejmJobKOctetsProcessedobject 👀.
sheetCompletedCopyNumber(95), Integer32 (-2..2147483647)
INTEGER:The number of the copy being stacked for the current document. This starts at 0, gets set to 1 when the first sheet of the first copy for each document is being stacked, and equals n when it's the nth sheet stacked in the current document copy. See section 3.4, entitled 'Monitoring Job Progress' 🥞.
sheetCompletedDocumentNumber(96), Integer32 (-2..2147483647)
INTEGER:The ordinal number of the document in the job that is currently being stacked. This starts at 0, goes up to 1 when the first sheet of the first document in the job is being stacked, and equals n when it's the nth document in the job, counting from 1 📑.
Implementations that only support one-document jobs SHOULD NOT implement this attribute 🙅♀️.
jobCollationType(97), JmJobCollationTypeTC
INTEGER:The type of job collation. See also Section 3.4, entitled 'Monitoring Job Progress' 🧃.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Impression attributes (110 - 129 decimal)
+
+ See the definition of the terms 'impression', 'sheet',
+ and 'page' in Section 2.
+
+ See also jmJobImpressionsPerCopyRequested and
+ jmJobImpressionsCompleted objects in the jmJobTable.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++impressionsSpooled(110), Integer32 (-2..2147483647)
INTEGER:The number of impressions spooled to the server or device for the job so far 🫧.
impressionsSentToDevice(111), Integer32 (-2..2147483647)
INTEGER:The number of impressions sent to the device for the job so far 🚀.
impressionsInterpreted(112), Integer32 (-2..2147483647)
INTEGER:The number of impressions interpreted for the job so far 🧠.
impressionsCompletedCurrentCopy(113),
Integer32 (-2..2147483647)
INTEGER:The number of impressions the device has completed for the current copy of the current document so far. For printing, completed impressions include interpreting, marking, and stacking the output. For other types of job services, they include the number of impressions processed 🖼️.
This value SHALL be reset to 0 for each document in the job and for each document copy 🔄.
fullColorImpressionsCompleted(114), Integer32 (-2..2147483647)
INTEGER:The number of full color impressions the device has completed for this job so far. For printing, completed impressions include interpreting, marking, and stacking the output. For other types of job services, they include the number of impressions processed. Full color impressions are typically those requiring 3 or more colorants, but this MAY vary by implementation 🌈. In any case, this attribute counts by 1 for each side that has full color, not by the number of colors per side. The other impression counters are incremented too, except highlightColorImpressionsCompleted(115) 💖.
Okay so this is where the highlight color counter comes in 🌈
highlightColorImpressionsCompleted(115),
Integer32 (-2..2147483647)This one counts the highlight color impressions the device has finished for this job so far 🖍️ For printing, "completed" covers interpreting, marking, and stacking the output. For other job services, it counts the impressions that were processed. Highlight color usually means black plus one other colorant, but this MAY vary by implementation. Either way, the value goes up by 1 for each side that has highlight color, and the other impression counters get incremented too, except fullColorImpressionsCompleted(114) 💖
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Page attributes (130 - 149 decimal)
+
+ See the definition of 'impression', 'sheet', and 'page'
+ in Section 2.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Page attributes time 📄✨ Start with the pages the job asked for:
pagesRequested(130), Integer32 (-2..2147483647)This is the number of logical pages the job wants processed 🎀
pagesCompleted(131), Integer32 (-2..2147483647)This tracks the logical pages completed for the job so far, and it gets a little tricky 👀 If the interpreter makes multiple copies in a single pass over the data, the final value SHALL be equal to the value of the pagesRequested object. If the interpreter instead processes the data again for each copy, the final value SHALL be a multiple of the value of the pagesRequested object 🔁
NOTE - See the impressionsCompletedCurrentCopy and pagesCompletedCurrentCopy attributes for attributes that are reset on each document copy.
NOTE - pagesCompleted can be paired with pagesRequested to show how far along the job is 📊 But only if you account for the multiplicative factor in implementations that make multiple copies.
pagesCompletedCurrentCopy(132), Integer32 (-2..2147483647)This one counts the logical pages completed for the current copy of the document so far. This value SHALL be reset to 0 for each document in the job and for each document copy 🔄
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Sheet attributes (150 - 169 decimal)
+
+ See the definition of 'impression', 'sheet', and 'page'
+ in Section 2.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Sheet attributes, bestie 🧻
sheetsRequested(150), Integer32 (-2..2147483647)This is the total number of medium sheets requested for this job. Unlike jmJobKOctetsPerCopyRequested and jmJobImpressionsPerCopyRequested, sheetsRequested(150) SHALL include the multiplicative factor from the number of copies. So it's the total number of sheets the job produces, not just the size of the document(s) that were submitted 📚
sheetsCompleted(151), Integer32 (-2..2147483647)This is the total number of medium sheets that have finished marking and stacking for the entire job so far. It doesn't matter whether those sheets were printed on one side or both 🙌
sheetsCompletedCurrentCopy(152), Integer32 (-2..2147483647)This counts the medium sheets that have finished marking and stacking for the current copy of a document in the job so far, again whether they're single-sided or double-sided. The value of this attribute SHALL be 0 before the job starts processing. It SHALL be reset to 1 after the first sheet of each document and document copy in the job is processed and stacked 🌸
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Resources attributes (requested and consumed) (170 - 189)
+
+ Pairs of these attributes can be used by monitoring
+ applications to show an indication of relative usage to
+ users, i.e., a 'thermometer'.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Resources attributes are giving thermometer energy 🌡️ Pairs of these can help monitoring apps show users how much of something has been used 💅
mediumRequested(170), JmMediumTypeTC
AND/OR
JmJobStringTC (SIZE(0..63))This is the medium the job needs, as a MULTI-ROW attribute. It's the type and/or the name of that medium 📄
NOTE - The name (JmJobStringTC) values line up with the name values of prtInputMediaName in the Printer MIB [print-mib], and with the name, size, and input tray values of the IPP 'media' attribute [ipp-model] 🫶
mediumConsumed(171), Integer32 (-2..2147483647)
AND
JmJobStringTC (SIZE(0..63))This is the number of sheets, plus the name of the medium, that have been consumed so far. Again, it doesn't matter whether those sheets were processed on one side or both 🧾 This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values.
NOTE - Same deal as above: the name values match prtInputMediaName in [print-mib] and the 'media' attribute in [ipp-model] 💜
colorantRequested(172), Integer32 (-2..2147483647)
AND/OR
JmJobStringTC (SIZE(0..63))This is the colorant the job requested, as a MULTI-ROW attribute. It's either the index (prtMarkerColorantIndex) in the Printer MIB [print-mib], the name of the colorant, or both 🎨
NOTE - The name (JmJobStringTC) values line up with the name values of prtMarkerColorantValue in the Printer MIB. Examples are: red, blue.
colorantConsumed(173), Integer32 (-2..2147483647)
AND/OR
JmJobStringTC (SIZE(0..63))This is the colorant that has been consumed, also MULTI-ROW. It's the index (prtMarkerColorantIndex) in the Printer MIB [print-mib] and/or the name of the colorant consumed 🖌️
NOTE - The name (JmJobStringTC) values line up with the name values of prtMarkerColorantValue in the Printer MIB. Examples are: red, blue
mediumTypeConsumed(174), Integer32 (-2..2147483647)
AND
JmJobStringTC (SIZE(0..63))This is the number of sheets of the indicated medium type consumed so far, no matter how many sides were used, plus the name of that medium type, as a MULTI-ROW attribute 🪄 This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values.
NOTE - The type name (JmJobStringTC) values line up with the type name values of prtInputMediaType in the Printer MIB [print-mib]. Values are: 'stationery', 'transparency', 'envelope', etc. These medium type names match the enum values of JmMediumTypeTC used in the mediumRequested attribute 💌
mediumSizeConsumed(175), Integer32 (-2..2147483647)
AND
JmJobStringTC (SIZE(0..63))This is the number of sheets of the indicated medium size consumed so far, again regardless of sides, plus the name of that size 📐 This attribute SHALL have both Integer32 and OCTET STRING (represented as JmJobStringTC) values.
NOTE - The size name (JmJobStringTC) values line up with the size name values in Appendix B of the Printer MIB [print-mib]. These size names are also a subset of the keyword values that [ipp-model] defines for the 'media' Job Template attribute. Values are: 'letter', 'a', 'iso-a4', 'jis-b4', etc. 🌈
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Time attributes (set by server or device) (190 - 209 decimal)
+
+ This section of attributes are ones that are set by the
+ server or device that accepts jobs. Two forms of time are
+ provided. Each form is represented in a separate attribute.
+ See section 3.1.2 and section 3.1.3 for the
+ conformance requirements for time attribute for agents and
+ monitoring applications, respectively. The two forms are:
+
+ 'DateAndTime' is an 8 or 11 octet binary encoded year,
+ month, day, hour, minute, second, deci-second with
+ optional offset from UTC. See SNMPv2-TC [SMIv2-TC].
+
+ NOTE: 'DateAndTime' is not printable characters; it is
+ binary.
+
+ 'JmTimeStampTC' is the time of day measured in the number of
+ seconds since the system was booted.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Time attributes are next, and these are set by the server or device that accepts jobs ⏰ There are two forms of time, each in its own attribute. Check section 3.1.2 and section 3.1.3 for the conformance requirements for agents and monitoring applications. The two forms are 'DateAndTime', an 8 or 11 octet binary encoded year, month, day, hour, minute, second, deci-second with an optional offset from UTC (see SNMPv2-TC [SMIv2-TC]), and 'JmTimeStampTC', the time of day as a count of seconds since the system was booted 🕰️
Also, 'DateAndTime' is binary, not printable characters, so don't go looking for readable text there 🙈
jobSubmissionToServerTime(190), JmTimeStampTC
AND/OR
DateAndTimeConfiguration 3 only: this is the time, and/or the date and time, that the job was submitted to the server. It's different from the device, which uses jobSubmissionTime 💻
jobSubmissionTime(191), JmTimeStampTC
AND/OR
DateAndTimeConfigurations 1, 2, and 3: this is the time, and/or the date and time, that the job was submitted to the server or device the agent is providing access to 📬
jobStartedBeingHeldTime(192), JmTimeStampTC
AND/OR
DateAndTimeThis is the time, and/or the date and time, that the job last entered the pendingHeld state. If the job has never entered pendingHeld, then the value SHALL be '0' or the attribute SHALL not be present in the table ⏸️
jobStartedProcessingTime(193), JmTimeStampTC
AND/OR
DateAndTimeThis is the time, and/or the date and time, that the job started processing 🚀
jobCompletionTime(194), JmTimeStampTC
AND/OR
DateAndTimeThis is the time, and/or the date and time, that the job entered the completed, canceled, or aborted state 🏁
jobProcessingCPUTime(195) Integer32 (-2..2147483647)
UNITS 'seconds'Last one for this batch! 💅 This is the CPU time in seconds that the job has spent in the processing state. If the job enters the processingStopped state, that elapsed time SHALL not be included. In other words, the jobProcessingCPUTime value SHOULD be relatively repeatable when the same job is processed again on the same device 🦋
3.3.9 Job State Reason bit definitions ✨
Okay so the JmJobStateReasonsNTC (N=1..4) textual-conventions are the hype squad for the jmJobStateReasons1 object and the jobStateReasonsN (N=2..4) attributes. They spill extra info about the current jmJobState value 🔍. These values MAY be used with any job state (or states) where the reason actually makes sense 💅.
NOTE — Real talk: you can't just add values tojmJobStatewithout breaking deployed clients that take action onjmJobStatevalues 😭. BUT the intent is that newJmJobStateReasonsNTCenums can be defined and registered without breaking those clients. So thejmJobStateReasons1object andjobStateReasonsNattributes are meant to be extensible 🌈.
NOTE — The Job Monitoring MIB has a superset of the IPP values [ipp-model] for the IPP 'job-state-reasons' attribute, because it's built to cover other job submission protocols too 🧚. Some reason names also changed from 'printer' to 'device', since the MIB covers more kinds of devices, including input devices like scanners 🫶.
3.3.9.1 JmJobStateReasons1TC specification
Multiple values MAY be used at the same time, so the standard values are defined in hexadecimal as powers of two 🦋. To make them easier to follow, they're presented in the order they're likely to happen (if implemented), starting with jobIncoming and ending with jobCompletedWithErrors 🎀.
other=0x1💖 — The job state reason is not one of the standardized or registered reasons.unknown=0x2🤷♀️ — The job state reason is not known to the agent or is indeterminent.jobIncoming=0x4📥 — The job has been accepted by the server or device, but the server or device is expecting (1) additional operations from the client to finish creating the job and/or (2) is accessing/accepting document data.submissionInterrupted=0x8💔 — The job was not completely submitted for some unforeseen reason, such as: (1) the server has crashed before the job was closed by the client, (2) the server or the document transfer method has crashed in some non-recoverable way before the document data was entirely transferred to the server, (3) the client crashed or failed to close the job before the time-out period.jobOutgoing=0x10🚀 — Configuration 2 only: The server is transmitting the job to the device.jobHoldSpecified=0x20🛑 — The value of the job'sjobHold(52)attribute is TRUE. The job SHALL NOT be a candidate for processing until this reason is removed and there are no other reasons to hold the job.jobHoldUntilSpecified=0x40⏳ — The value of the job'sjobHoldUntil(53)attribute specifies a time period that is still in the future. The job SHALL NOT be a candidate for processing until this reason is removed and there are no other reasons to hold the job.jobProcessAfterSpecified=0x80🕰️ — The value of the job'sjobProcessAfterDateAndTime(51)attribute specifies a time that is still in the future. The job SHALL NOT be a candidate for processing until this reason is removed and there are no other reasons to hold the job.resourcesAreNotReady=0x100📦 — At least one of the resources needed by the job, such as media, fonts, resource objects, etc., is not ready on any of the physical devices for which the job is a candidate. This condition MAY be detected when the job is accepted, or subsequently while the job is pending or processing, depending on implementation.deviceStoppedPartly=0x200🌗 — One or more, but not all, of the devices to which the job is assigned are stopped. If all of the devices are stopped (or the only device is stopped), thedeviceStoppedreason SHALL be used.deviceStopped=0x400🧊 — The device(s) to which the job is assigned is (are all) stopped.jobInterpreting=0x800🧠 — The device to which the job is assigned is interpreting the document data.jobPrinting=0x1000🖨️ — The output device to which the job is assigned is marking media. This value is useful for servers and output devices which spend a great deal of time processing (1) when no marking is happening and then want to show that marking is now happening, or (2) when the job is in the process of being canceled or aborted while the job remains in the processing state, but the marking has not yet stopped so that impression or sheet counts are still increasing for the job.jobCanceledByUser=0x2000🙅♀️ — The job was canceled by the owner of the job, i.e., by a user whose name is the same as the value of the job'sjmJobOwnerobject, or by some other authorized end-user, such as a member of the job owner's security group.jobCanceledByOperator=0x4000🧑💼 — The job was canceled by the operator, i.e., by a user who has been authenticated as having operator privileges (whether local or remote).jobCanceledAtDevice=0x8000🕹️ — The job was canceled by an unidentified local user, i.e., a user at a console at the device.abortedBySystem=0x10000🚨 — The job (1) is in the process of being aborted, (2) has been aborted by the system and placed in the 'aborted' state, or (3) has been aborted by the system and placed in the 'pendingHeld' state, so that a user or operator can manually try the job again.processingToStopPoint=0x20000🧹 — The requester has issued an operation to cancel or interrupt the job or the server/device has aborted the job, but the server/device is still performing some actions on the job until a specified stop point occurs or job termination/cleanup is completed.
This reason is recommended to be used in conjunction with the processing job state to indicate that the server/device is still performing some actions on the job while the job remains in the processing state. After all the job's resources consumed counters have stopped incrementing, the server/device moves the job from the processing state to the canceled or aborted job states.
serviceOffLine=0x40000📴 — The service or document transform is off-line and accepting no jobs. All pending jobs are put into thependingHeldstate. This situation could be true if the service's or document transform's input is impaired or broken.jobCompletedSuccessfully=0x80000🎉 — The job completed successfully.jobCompletedWithWarnings=0x100000⚠️ — The job completed with warnings.jobCompletedWithErrors=0x200000💀 — The job completed with errors (and possibly warnings too).
The following additional job state reasons have been added to represent job states that are in ISO DPA [iso-dpa] and other job submission protocols:
jobPaused=0x400000⏸️ — The job has been indefinitely suspended by a client issuing an operation to suspend the job so that other jobs may proceed using the same devices. The client MAY issue an operation to resume the paused job at any time, in which case the agent SHALL remove thejobPausedvalues from the job'sjmJobStateReasons1object and the job is eventually resumed at or near the point where the job was paused.jobInterrupted=0x800000🔀 — The job has been interrupted while processing by a client issuing an operation that specifies another job to be run instead of the current job. The server or device will automatically resume the interrupted job when the interrupting job completes.jobRetained=0x1000000🗄️ — The job is being retained by the server or device with all of the job's document data (and submitted resources, such as fonts, logos, and forms, if any). Thus a client could issue an operation to the server or device to either (1) re-do the job (or a copy of the job) on the same server or device or (2) resubmit the job to another server or device. When a client could no longer re-do/resubmit the job, such as after the document data has been discarded, the agent SHALL remove thejobRetainedvalue from thejmJobStateReasons1object.
These bit definitions are the equivalent of a type 2 enum, except that combinations of bits may be used together. See section 3.7.1.2. The remaining bits are reserved for future standardization and/or registration. 🌸
3.3.9.2 JmJobStateReasons2TC specification ✨
okay bestie, this is the big list of job state reason bits 🎀 every value is a hex power of two, so you can stack them. multiple values MAY be used at the same time, so one job can be having a whole crisis at once 💅
cascaded(0x1): an outbound gateway has sent all of the job's job and document attributes and data to another spooling system 🦋deletedByAdministrator(0x2): the administrator has deleted the job 💀discardTimeArrived(0x4): the job got deleted because the time in itsjob-discard-timeattribute has arrived ⏰postProcessingFailed(0x8): the post-processing agent failed while it was trying to log accounting attributes for the job. so the job got put into the completed state with thejobRetainedjmJobStateReasons1 object value for a system-defined period of time, so the administrator can look at it, resubmit it, etc. 🫶jobTransforming(0x10): the server/device is interpreting document data and making another electronic representation 🌈maxJobFaultCountExceeded(0x20): the job has faulted several times and went past the administratively defined fault count limit 😭devicesNeedAttentionTimeOut(0x40): one or more document transforms the job is using needs a human to step in so the job can keep going, but nobody showed up within the site-settable time-out value 🙈needsKeyOperatorTimeOut(0x80): one or more devices or document transforms the job is using need a specially trained operator (who may need a key to unlock the device and get access) to move things along, but the key operator didn't come within the site-settable time-out value 🔑jobStartWaitTimeOut(0x100): the server/device stopped the job at the very beginning of processing so a human can do something, like install a special cartridge or special non-standard media. nobody resumed it within the site-settable time-out value, so the server/device moved the job to thependingHeldstate 🧚jobEndWaitTimeOut(0x200): the server/device stopped the job at the very end of processing so a human can do something, like remove a special cartridge or put standard media back. nobody resumed it within the site-settable time-out value, so the server/device moved the job to thecompletedstate 🍓jobPasswordWaitTimeOut(0x400): the server/device stopped the job at the beginning of processing to wait for the job's password, but the password never came in within the site-settable time-out value 🔐deviceTimedOut(0x800): a device the job was using didn't respond within the period set by that device's site-settable attribute 🌸connectingToDeviceTimeOut(0x1000): the server is trying to connect to one or more devices that might be dial-up, polled, or queued, so they could be busy with traffic from other systems. the server couldn't connect within the site-settable time-out value 📞transferring(0x2000): the job is being moved to a downstream server or downstream device ➡️queuedInDevice(0x4000): the server/device has queued the job in a downstream server or downstream device 📥jobQueued(0x8000): the server/device has queued the document data 🗂️jobCleanup(0x10000): the server/device is doing cleanup as part of wrapping up normal processing 🧹jobPasswordWait(0x20000): the server/device picked this job to be next, but instead of getting resources and starting it, it moved the job to thependingHeldstate to wait for a password (and it dispatched another job, if there was one) 🔒validating(0x40000): the server/device is checking the job after accepting it ✅queueHeld(0x80000): the operator has held the entire job set or queue ✋jobProofWait(0x100000): the job made a single proof copy and is sitting in thependingHeldstate, waiting for the requester to send an operation that releases the job to print normally. any job and document copy attributes from the original submission still get obeyed 🖨️heldForDiagnostics(0x200000): the system is running intrusive diagnostics, so every job is being held 🩺noSpaceOnServer(0x800000): there isn't room on the server to store all of the job 📦pinRequired(0x1000000): the System Administrator settable device policy is (1) to require PINs, and (2) to hold jobs that don't have a PIN supplied as an input parameter when the job was created 📌exceededAccountLimit(0x2000000): the account this job draws from has gone over its limit. this condition SHOULD be detected before the job gets scheduled, so the user doesn't wait for the job to be scheduled only to find out the account is overdrawn 💸. this condition MAY also happen while the job is processing, either when processing begins or partway throughheldForRetry(0x4000000): the job ran into errors the server/device couldn't recover from with its normal retry procedures, but the errors might not happen if the job gets processed again later. examples are a busy phone number or a remote file system that can't be accessed. in that situation, the server/device SHALL move the job from processing topendingHeld, not toaborted🔄
The following values are from the X/Open PSIS draft standard:
canceledByShutdown(0x8000000): the job was canceled because the server or device shut down before the job finished 🌙deviceUnavailable(0x10000000): the system aborted this job because the device can't accept jobs right now 🚫wrongDevice(0x20000000): the system aborted this job because the device can't handle this particular job. the spooler SHOULD try another device, or the user should send the job to a different device 🔀badJob(0x40000000): the system aborted this job because it has a major problem, like an ill-formed PDL. the spooler SHOULD not even try another device 🙅♀️
These bit definitions work like a type 2 enum, except you can combine them. See section 3.7.1.2. 💖
3.3.9.3 JmJobStateReasons3TC specification ✨
this textual-convention goes with the jobStateReasons3 attribute and gives extra info about the jmJobState object 🦋 the values are hex powers of two, and multiple values may be used at the same time 💜
jobInterruptedByDeviceFailure(0x1): a device or the print system software the job was using failed while the job was processing. the server or device keeps the job in thependingHeldstate until an operator figures out what to do with it 😱
These bit definitions work like a type 2 enum, except you can combine them. See section 3.7.1.2. The remaining bits are reserved for future standardization and/or registration. 🎀
3.3.9.4 JmJobStateReasons4TC specification ✨
this one goes with the jobStateReasons4 attribute and also gives extra info about the jmJobState object 🌈 the values are hex powers of two, and multiple values MAY be used at the same time 🫶
None defined at this time. 🌸
These bit definitions work like a type 2 enum, except you can combine them. See section 3.7.1.2. The remaining bits are reserved for future standardization and/or registration. 👑
3.4 Monitoring Job Progress ✨
okay bestie, this section is all about watching how far a job has gotten 📈💖 there are a bunch of objects and attributes that count the K octets, impressions, sheets, and pages that were requested or completed 🧚 for impressions and sheets, "completed" means stacked 🥞 unless the implementation can't detect when each sheet gets stacked, in which case stacked is approximated when processing of each sheet finishes 🎀 there are objects and attributes for the whole job, and also for the current copy of the document being stacked 👑 for that second one, how fast the counters go up depends on the sheet and document collation of the job, so pay attention to that part ✨
Job collation is made of two things: sheet collation and document collation 💅 sheet collation is the ordering of sheets within a document copy, and document collation is the ordering of document copies within a multi-document job 🫶 there are three types of job collation (check Section 2 for the terminology definitions) 🦋
uncollatedSheets(3)- no collation of the sheets within each document copy, i.e., each sheet of a document that is to produce multiple copies is replicated before the next sheet in the document is processed and stacked. If the device has an output bin collator, theuncollatedSheets(3)value may actually produce collated sheets as far as the user is concerned (in the output bins). However, when the job collation is the to a monitoring application between a device that has an output bin collator and one that does not.collatedDocuments(4)- collation of the sheets within each document copy is performed within the printing device by making multiple passes over either the source or an intermediate representation of the document. In addition, when there are multiple documents per job, the i'th copy of each document is stacked before the j'th copy of each document, i.e., the documents are collated within each job copy. For example, if a job is submitted with documents, A and B, the job is made available to the end user as: A, B, A, B, .... ThecollatedDocuments(4)value corresponds to the IPP [ipp-model]separate-documents-collated-copiesvalue of the "multiple-document-handling" attribute. If jobCopiesRequested or documentCopiesRequested = 1, then jobCollationType is defined as 4.uncollatedDocuments(5)- collation of the sheets within each document copy is performed within the printing device by making multiple passes over either the source or an intermediate representation of the document. In addition, when there are multiple documents per job, all copies of the first document in the job are stacked before the any copied of the next document in the job, i.e., the documents are uncollated within the job. For example, if a job is submitted with documents, A and B, the job is mad available to the end user as: A, A, ..., B, B, .... TheuncollatedDocuments(5)value corresponds to the IPP [ipp-model]separate-documents-uncollated-copiesvalue of the "multiple-document-handling" attribute.
Now here are the four variables that track a job's impression progress 🌸
jmJobImpressionsCompleted- counts the total number of impressions stacked for the jobimpressionsCompletedCurrentCopy- counts the number of impressions stacked for the current document copysheetCompletedCopyNumber- identifies the number of the copy for the current document being stacked, where the first copy is 1.sheetCompletedDocumentNumber- identifies the current document within the job that is being stacked, where the first document in a job is 1. NOTE: this attribute SHOULD NOT be implemented for implementations that only support one document per job.
For each of the three types of job collation, let's look at a job with three copies of two documents (1, 2), where each document has 3 impressions 🍓 these show the four variables' values as each sheet is stacked for one-sided printing 🙈
Job Collation Type = uncollatedSheets(3)
jmJobImpressions Impressions sheetCompleted sheetCompleted
Completed CompletedCurrent CopyNumber DocumentNumber
Copy
0 0 0 0
1 1 1 1
2 1 2 1
3 1 3 1
4 2 1 1
5 2 2 1
6 2 3 1
7 3 1 1
8 3 2 1
9 3 3 1
10 1 1 2
11 1 2 2
12 1 3 2
13 2 1 2
14 2 2 2
15 2 3 2
16 3 1 2
17 3 2 2
18 3 3 2 Job Collation Type = collatedDocuments(4)
JmJobImpressions Impressions sheetCompleted sheetCompleted
Completed CompletedCurrent CopyNumber DocumentNumber
Copy
0 0 0 0
1 1 1 1
2 2 1 1
3 3 1 1
4 1 1 2
5 2 1 2
6 3 1 2
7 1 2 1
8 2 2 1
9 3 2 1
10 1 2 2
11 2 2 2
12 3 2 2
13 1 3 1
14 2 3 1
15 3 3 1
16 1 3 2
17 2 3 2
18 3 3 2 Job Collation Type = uncollatedDocuments(5)
jmJobImpressions Impressions sheetCompleted sheetCompleted
Completed CompletedCurrent CopyNumber DocumentNumber
Copy
0 0 0 0
1 1 1 1
2 2 1 1
3 3 1 1
4 1 2 1
5 2 2 1
6 3 2 1
7 1 3 1
8 2 3 1
9 3 3 1
10 1 1 2
11 2 1 2
12 3 1 2
13 1 2 2
14 2 2 2
15 3 2 2
16 1 3 2
17 2 3 2
18 3 3 23.5 Job Identification ✨
okay so there are a bunch of attributes that help a user, operator, or system admin find the jobs they care about 🔍 stuff like jobURI, jobName, jobOriginatingHost, and so on 💜 there's also the jmJobSubmissionID object, which is a text string table index 🎀 being a table index is the best part, because a monitoring app can zoom straight to a particular job that was submitted from a particular client by the user running the app, without scrolling through the whole job table 🦋 the Job Monitoring MIB needs to identify the job on both sides of the job submission process 🫶 the primary identification point is the client side, and the jmJobSubmissionID lets the monitoring app pick out the job it wants from every job the server or device currently "knows" about ✨ the value of jmJobSubmissionID can be assigned by either the client's local system or a downstream server or device, and where it gets assigned depends on the job submission protocol in use 👑
The server/device-side identifier, called the jmJobIndex object, SHALL be assigned by the SNMP Job Monitoring MIB agent when the server or device accepts jobs from submitting clients 💖 the jmJobIndex object lets the interested party grab every object they want that relates to a particular job. See Section 3.2, entitled 'The Job Tables and the Oldest Active and Newest Active Indexes' for the specification of how the agent SHALL assign the jmJobIndex values 🧚
The MIB also has a mapping table that maps each jmJobSubmissionID value to its matching jmJobIndex value generated by the agent 🌈 so an application can find the right jmJobIndex for its job in a single Get operation, just from the Job Submission ID. See the jmJobIDGroup 🍓
Sometimes more than one application program watches the same job as it passes from one network entity to another during submission. See configuration 3. When there are multiple job submission IDs, each entity MAY supply an appropriate jmJobSubmissionID value 🙈 in that case there would be a separate entry in the jmJobSubmissionID table for each one, and all of those entries would map to the same jmJobIndex that holds the job data 🫶 when the job gets deleted, it's up to the agent to remove all entries that point to the job from the jmJobSubmissionID table as well 💅
The jobName attribute gives a name that the user supplies as a job attribute with the job 🎀 the jobName attribute is not necessarily unique, even for one user, let alone across users 💀
3.5.1 The Job Submission ID specifications ✨
okay so this is where the formats for every registered Job Submission ID get spelled out 🎀 and yes, the JmJobSubmissionIDTypeTC uses this format, so it's kind of a big deal. each ID is a fixed-length, 48-octet printable US-ASCII [US-ASCII] string with no control characters, and it's split into three chunks:
octet 1: The format letter identifying the format. The
US-ASCII characters '0-9', 'A-Z', and 'a-z' are assigned
in order giving 62 possible formats.
octets 2-40: A 39-character, US-ASCII trailing SPACE
filled field specified by the format letter, if the data
is less than 39 ASCII characters.
octets 41-48: A sequential or random US-ASCII number to
make the ID quasi-unique.bestie, the vibe here is all about who makes the ID. if the client doesn't supply a job submission ID in the job submission protocol, then the agent SHALL assign one using any of the standard formats that are reserved for the agent 🧚 and then there's the ID-clash rule: Clients SHALL not use formats that are reserved for agents, and agents SHALL NOT use formats that are reserved for clients, so ID generation doesn't get messy 💅 check the description to see which formats belong to clients and which belong to agents.
adding new formats is a thing too. registration of additional formats may be done following the procedures described in Section 3.7.3 🌸
now, the formats that were defined when this spec was completed. the layout is below, and every single line is verbatim so nothing gets lost:
Format
Letter Description
------ ------------
'0' Job Owner generated by the server/device
octets 2-40: The last 39 bytes of the jmJobOwner object.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the agent.
This format is reserved for agents.
NOTE - Clients wishing to use a job submission ID that
incorporates the job owner, SHALL use format '8', not
format '0'.
'1' Job Name
octets 2-40: The last 39 bytes of the jobName attribute.
octets 41-48: The US-ASCII 8-decimal-digit random number
assigned by the client.
This format is reserved for clients.
'2' Client MAC address
octets 2-40: The client MAC address: in hexadecimal with
each nibble of the 6 octet address being '0'-'9' or
'A' - 'F' (uppercase only). Most significant octet first.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'3' Client URL
octets 2-40: The last 39 bytes of the client URL [URI-spec].
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'4' Job URI
octets 2-40: The last 39 bytes of the URI [URI-spec]
assigned by the server or device to the job when the job
was submitted for processing.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the agent.
This format is reserved for agents.
'5' POSIX User Number
octets 2-40: The last 39 bytes of a user number, such as
POSIX user number.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'6' User Account Number
octets 2-40: The last 39 bytes of the user account number.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'7' DTMF Incoming FAX routing number
octets 2-40: The last 39 bytes of the DTMF incoming FAX
routing number.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'8' Job Owner supplied by the client
octets 2-40: The last 39 bytes of the job owner name (that the
agent returns in the jmJobOwner object).
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients. See format '0' which is
reserved for agents.
'9' Host Name
octets 2-40: The last 39 bytes of the host name with trailing
SPACES that submitted the job to this server/device using
a protocol, such as LPD [RFC1179] which includes the host
name in the job submission protocol.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the job id generated by the submitting
server (configuration 3) or the client (configuration 1
and 2), such as in the LPD protocol.
This format is reserved for clients.
'A' AppleTalk Protocol
octets 2-40: Contains the AppleTalk printer name, with the
first character of the name in octet 2. AppleTalk printer
names are a maximum of 31 characters. Any unused portion
of this field shall be filled with spaces.
octets 41-48: '00000XXX', where 'XXX' is the 3-digit US-ASCII
decimal representation of the Connection Id.
This format is reserved for agents.
'B' NetWare PServer
octets 2-40: Contains the Directory Path Name as recorded by
the Novell File Server in the queue directory. If the
string is less than 40 octets, the left-most character in
the string shall appear in octet position 2. Otherwise,
only the last 39 bytes shall be included. Any unused
portion of this field shall be filled with spaces.
octets 41-48: '000XXXXX' The US-ASCII representation of the
Job Number as per the NetWare File Server Queue Management
Services.
This format is reserved for agents.
'C' Server Message Block protocol (SMB)
octets 2-40: Contains a decimal (US-ASCII coded)
representation of the 16 bit SMB Tree Id field, which
uniquely identifies the connection that submitted the job
to the printer. The most significant digit of the numeric
string shall be placed in octet position 2. All unused
portions of this field shall be filled with spaces. The
SMB Tree Id has a maximum value of 65,535.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the File Handle returned from the device
to the client in response to a Create Print File command.
This format is reserved for agents.
'D' Transport Independent Printer/System Interface (TIP/SI)
octets 2-40: Contains the Job Name from the Job Control-Start
Job (JC-SJ) command. If the Job Name portion is less than
40 octets, the left-most character in the string shall
appear in octet position 2. Any unused portion of this
field shall be filled with spaces. Otherwise, only the
last 39 bytes shall be included.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the jmJobIndex assigned by the agent.
This format is reserved for agents, since the agent supplies
octets 41-48, though the client supplies the job name.
See format '1' reserved to clients to submit job name ids
in which they supply octets 41-48.
'E' IPDS on the MVS or VSE platform
octets 2-40: Contains bytes 2-27 of the XOH Define Group
Boundary Group ID triplet. Octet position 2 MUST carry
the value x'01'. Bytes 28-40 MUST be filled with spaces.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the jmJobIndex assigned by the agent.
This format is reserved for agents, since the agent supplies
octets 41-48, though the client supplies the job name.
'F' IPDS on the VM platform
octets 2-40: Contains bytes 2-31 of the XOH Define Group
Boundary Group ID triplet. Octet position 2 MUST carry
the value x'02'. Bytes 32-40 MUST be filled with spaces.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the jmJobIndex assigned by the agent.
This format is reserved for agents, since the agent supplies
octets 41-48, though the client supplies the file name.
'G' IPDS on the OS/400 platform
octets 2-40: Contains bytes 2-36 of the XOH Define Group
Boundary Group ID triplet. Octet position 2 MUST carry
the value x'03'. Bytes 37-40 MUST be filled with spaces.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the jmJobIndex assigned by the agent.
This format is reserved for agents, since the agent supplies
octets 41-48, though the client supplies the job name.⚠️ babe, the format letter is the key to the whole thing. the ID is only as good as the format it was built with, so always check which side (client or agent) a format is reserved for before you use it 🫶
okay, now the reality check 🥹 the job submission id is only meant to be unique between a limited set of clients, for a limited amount of time (basically the life of the job, in the context of the server or device that's processing it) 🦋 some formats mix in something unique per client plus a random number, so the same job submitted by the same client still gets a different ID. for formats where part of the ID is already guaranteed unique per client, like the MAC address or the URL, a sequential number SHOULD suffice for each client, and it's probably easier for each client to manage too. so the length was picked to make collisions super unlikely, but it's NOT a guarantee of uniqueness. collisions are still remotely possible, though they wouldn't cause bad consequences, because this MIB is only meant for monitoring jobs, not for controlling or managing them 🌈
3.6 Internationalization Considerations 🌍
okay this part covers the internationalization considerations that are included in this MIB 💖
3.6.1. Text generated by the server or device 💖
Okay bestie, so there are a few objects and attributes that the server or device generates itself, and they SHALL be represented using the Universal Multiple-Octet Coded Character Set (UCS) [ISO-10646]. The agent always supplies these (if it's implemented), not the job submitting client 🙈
jmGeneralJobSetNameobjectprocessingMessage(6)attributephysicalDevice(32)(name value) attribute
The character encoding for these SHALL be UTF-8, as REQUIRED by RFC 2277 [RFC2277]. The JmUTF8StringTC textual convention is how we flag UTF-8 text strings ✨
NOTE - For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation of 7-bit ASCII is identical to the US-ASCII [US-ASCII] encoding.
The text in the processingMessage(6) attribute is generated by the server/device 🤖 Its natural language is identified by the processingMessageNaturalLangTag(7) attribute. That one uses the JmNaturalLanguageTagTC textual convention, which SHALL conform to the language tag mechanism in RFC 1766 [RFC1766]. The JmNaturalLanguageTagTC value is the same as the IPP [ipp-model] 'naturalLanguage' attribute syntax. RFC 1766 says it's a US-ASCII string made of the natural language, followed by an optional country field. Both fields use the same two-character codes from ISO 639 [ISO-639] and ISO 3166 [ISO-3166], respectively, which the Printer MIB also uses for identifying language and country 🌸
Examples of processingMessageNaturalLangTag(7) values include:
'en'for English'en-us'for US English'fr'for French'de'for German
3.6.2. Text supplied by the job submitter 🎀
Every object and attribute represented by the 'JmJobStringTC' textual convention is either (1) supplied in the job submission protocol by the client that submits the job to the server or device, or (2) defaulted by the server or device if the job submitting client doesn't supply values. The agent SHALL represent these objects and attributes in the MIB either (1) in the coded character set they were submitted in, or (2) MAY convert the coded character set to another coded character set or encoding scheme. In any case, the resulting coded character set representation SHOULD be UTF-8 [UTF-8], but SHALL be one in which the code positions from 0 to 31 is not used, 32 to 127 is US-ASCII [US-ASCII], 127 is not unused, and the remaining code positions 128 to 255 represent single-byte or multi-byte graphic characters structured according to ISO 2022 [ISO-2022] or are unused. It's giving very specific, and that's the point 💅
The coded character set SHALL be one of the ones registered with IANA [IANA], and SHALL be identified by the jobCodedCharSet attribute in the jmJobAttributeTable for the job. If the agent doesn't know what coded character set the job submitting client used, the agent SHALL either (1) return the 'unknown(2)' value for the jobCodedCharSet attribute, or (2) not return the jobCodedCharSet attribute for the job 🤷♀️
Examples of coded character sets that meet this criteria for use as the value of the jobCodedCharSet job attribute are:
- US-ASCII [US-ASCII]
- ISO 8859-1 (Latin-1) [ISO-8859-1]
- any ISO 8859-n
- HP Roman8
- IBM Code Page 850
- Windows Default 8-bit set
- UTF-8 [UTF-8]
- US-ASCII plus JIS X0208-1990 Japanese [JIS X0208]
- US-ASCII plus GB2312-1980 PRC Chinese [GB2312]
See the IANA registry of coded character sets [IANA charsets] 🗂️
Examples of coded character sets that do NOT meet this criteria are: national 7-bit sets conforming to ISO 646 (except US-ASCII), EBCDIC, and ISO 10646 (Unicode) [ISO-10646]. To represent Unicode characters, the UTF-8 [UTF-8] encoding scheme SHALL be used, which has been assigned the MIBenum value of '106' by IANA 🌈
The jobCodedCharSet attribute uses the imported 'CodedCharSet' textual convention from the Printer MIB [printmib].
The natural language for attributes represented by the JmJobStringTC textual convention is identified either (1) by the jobNaturalLanguageTag(9) attribute, or it's keywords in US-English (as in IPP). A monitoring application SHOULD attempt to localize keywords into the user's language using some lookup mechanism. If the keyword value isn't known to the monitoring application, the monitoring application SHOULD assume the value is in the natural language specified by the job's jobNaturalLanguageTag(9) attribute, and SHOULD present the value to its user as is. The jobNaturalLanguageTag(9) attribute value SHALL have the same syntax and semantics as the processingMessageNaturalLangTag(7) attribute, except that jobNaturalLanguageTag(9) identifies the natural language of attributes supplied by the job submitter, instead of the natural language of the processingMessage(6) attribute. See Section 3.6.1. 🧠
3.6.3. 'DateAndTime' for representing the date and time ⏰
This MIB also contains objects that are represented using the DateAndTime textual convention from SMIv2 [SMIv2-TC]. The job management application SHALL display such objects in the locale of the user running the monitoring application 🌍
3.7. IANA and PWG Registration Considerations 🦋
This MIB doesn't require any extra registration schemes for IANA, but it does depend on registration schemes that other Internet standards track specifications have already set up. The names of these IANA registration assignments under the /in-notes/iana/assignments/ path are:
printer-language-numbers- used as enums in the documentFormat(38) attributemedia-types- uses as keywords in the documentFormat(38) attributecharacter-sets- used as enums in the jobCodedCharSet(8) attribute
The Printer Working Group (PWG) will handle registration of additional enums after this standard is approved, following the procedures described in this section 📋
3.7.1. PWG Registration of enums 💜
This specification uses textual conventions to define enumerated values (enums) and bit values. Enumerations (enums) and bit values are sets of symbolic values defined for use with one or more objects or attributes. Every enumeration set and bit value set gets a symbolic data type name (textual convention). By convention, the symbolic name ends in "TC" for textual convention. These enumerations are defined at the beginning of the MIB module specification.
The PWG has defined several types of enumerations for use in the Job Monitoring MIB and the Printer MIB [print-mib]. These types differ in how new enumerations get added. Throughout this document, references to "type n enum", where n can be 1, 2 or 3, can be found in the various tables. The definitions of these types of enumerations are:
3.7.1.1. Type 1 enumerations 🔒
Type 1 enumeration: All the values are defined in the Job Monitoring MIB specification (RFC for the Job Monitoring MIB). Additional enumerated values require a new RFC.
There are no type 1 enums in the current document.
3.7.1.2. Type 2 enumerations 🌷
Type 2 enumeration: An initial set of values is defined in the Job Monitoring MIB specification. Additional enumerated values are registered with the PWG.
The following type 2 enums are contained in the current document:
- JmUTF8StringTC
- JmJobStringTC
- JmNaturalLanguageTagTC
- JmTimeStampTC
- JmFinishingTC [same enum values as IPP "finishing" attribute]
- JmPrintQualityTC [same enum values as IPP "print-quality" attribute]
- JmTonerEconomyTC
- JmMediumTypeTC
- JmJobSubmissionIDTypeTC
- JmJobCollationTypeTC
- JmJobStateTC [same enum values as IPP "job-state" attribute]
- JmAttributeTypeTC
The textual conventions that have the same enum values as the indicated IPP Job attribute are simultaneously registered by the PWG for use with IPP [ipp-model] and the Job Monitoring MIB 🤝
3.7.1.3. Type 3 enumeration 🌙
Type 3 enumeration: An initial set of values is defined in the Job Monitoring MIB specification. Additional enumerated values are registered through the PWG without PWG review.
There are no type 3 enums in the current document.
3.7.2. PWG Registration of type 2 bit values 🌈
This memo contains the following type 2 bit value textual conventions:
- JmJobServiceTypesTC
- JmJobStateReasons1TC
- JmJobStateReasons2TC
- JmJobStateReasons3TC
- JmJobStateReasons4TC
These textual conventions are defined as bits in an Integer, so they can be used with SNMPv1 SMI. The jobStateReasonsN (N=1..4) attributes are defined as bit values using the corresponding JmJobStateReasonsNTC textual conventions ✨
The registration of JmJobServiceTypesTC and JmJobStateReasonsNTC bit values follows the procedures for a type 2 enum, as specified in Section 3.7.1.2.
3.7.3. PWG Registration of Job Submission Id Formats 🧚
In addition to enums and bit values, this specification assigns a single ASCII digit or letter to various job submission ID formats. See the JmJobSubmissionIDTypeTC textual convention and the object. The registration of JobSubmissionID format numbers follows the procedures for a type 2 enum, as specified in Section 3.7.1.2.
3.7.4. PWG Registration of MIME types/sub-types for document-formats 🍓
The documentFormat(38) attribute has MIME type/sub-type values for indicating document formats, which IANA registers as "media type" names. The values of the documentFormat(38) attribute are the same as the corresponding Internet Printing Protocol (IPP) "document-format" Job attribute values [ipp-model].
3.8. Security Considerations 🔐
Okay, security time, and I'm not joking around here 😭
3.8.1. Read-Write objects 🙈
All objects are read-only, which greatly simplifies the security considerations. If another MIB augments this MIB, that MIB might accept SNMP Write operations to objects in that MIB whose effect is to modify the values of read-only objects in this MIB. However, that MIB SHALL have to support the required access control in order to achieve security, not this MIB. Main character energy for whoever's writing that other MIB 👑
3.8.2. Read-Only Objects In Other User's Jobs 👀
The security policy of some sites MAY be that unprivileged users can only get the objects from jobs they submitted, plus a few minimal objects from other jobs, such as the jmJobKOctetsPerCopyRequested and jmJobKOctetsProcessed objects, so that a user can tell how busy a printer is. Other sites MAY allow all unprivileged users to see all objects of all jobs. This MIB doesn't require, nor does it specify how, such restrictions would be implemented. A monitoring application SHOULD enforce the site security policy when returning information to an unprivileged end user who is using the monitoring application to monitor jobs that don't belong to that user, i.e., the jmJobOwner object in the jmJobTable does not match the user's user name 🚫
An operator is a privileged user who would be able to see all objects of all jobs, independent of the policy for unprivileged users 🗝️
3.9. Notifications 🔔
This MIB doesn't specify any notifications. For simplicity, management applications are expected to poll for status. The jmGeneralJobPersistence and jmGeneralAttributePersistence objects help an application figure out the polling rate. The resulting network traffic is not expected to be significant 🌸
4. MIB specification 💅
okay bestie, this is the main event 💅✨ the actual Job Monitoring MIB, all of it 🎀
Job-Monitoring-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, enterprises,
Integer32 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
-- The following textual-conventions are needed to implement
-- certain attributes, but are not needed to compile this MIB.
-- They are provided here for convenience:
-- hrDeviceIndex FROM HOST-RESOURCES-MIB
-- DateAndTime FROM SNMPv2-TC
-- PrtInterpreterLangFamilyTC,
-- CodedCharSet FROM Printer-MIB
-- Use the enterprises arc assigned to the PWG which is pwg(2699).
-- Group all PWG mibs under mibs(1).
jobmonMIB MODULE-IDENTITY
LAST-UPDATED "9902190000Z"
ORGANIZATION "Printer Working Group (PWG)"
CONTACT-INFO
"Tom Hastings
Postal: Xerox Corp.
Mail stop ESAE-231
701 S. Aviation Blvd.
El Segundo, CA 90245
Tel: (301)333-6413
Fax: (301)333-5514
E-mail: hastings@cp10.es.xerox.com
Send questions and comments to the Printer Working Group (PWG)
using the Job Monitoring Project (JMP) Mailing List:
jmp@pwg.org
For further information, including how to subscribe to the
jmp mailing list, access the PWG web page under 'JMP':
http://www.pwg.org/
Implementers of this specification are encouraged to join the
jmp mailing list in order to participate in discussions on any
clarifications needed and registration proposals being reviewed
in order to achieve consensus."
DESCRIPTION
"The MIB module for monitoring job in servers, printers, and
other devices.
Version: 1.0"
-- revision history
REVISION "9902190000Z"
DESCRIPTION " This version published as RFC 2707"
::= { enterprises pwg(2699) mibs(1) jobmonMIB(1) }
-- Textual conventions for this MIB module
JmUTF8StringTC ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"To facilitate internationalization, this TC represents
information taken from the ISO/IEC IS 10646-1 character set,
encoded as an octet string using the UTF-8 character encoding
scheme.
See section 3.6.1, entitled: 'Text generated by the server or
device'."
SYNTAX OCTET STRING (SIZE (0..63))
JmJobStringTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"To facilitate internationalization, this TC represents
information using any coded character set registered by IANA as
specified in section 3.7. While it is recommended that the
coded character set be UTF-8 [UTF-8], the actual coded
character set SHALL be indicated by the value of the
jobCodedCharSet(8) attribute for the job.
See section 3.6.2, entitled: 'Text supplied by the job
submitter'."
SYNTAX OCTET STRING (SIZE (0..63))
JmNaturalLanguageTagTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An IETF RFC 1766-compliant 'language tag', with zero or more
sub-tags that identify a natural language. While RFC 1766
specifies that the US-ASCII values are case-insensitive, this
MIB specification requires that all characters SHALL be lower
case in order to simplify comparing by management applications.
See section 3.6.1, entitled: 'Text generated by the server or
device' and section 3.6.2, entitled: 'Text supplied by the job
submitter'."
SYNTAX OCTET STRING (SIZE (0..63))
JmTimeStampTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The simple time at which an event took place. The units are
in seconds since the system was booted.
NOTE - JmTimeStampTC is defined in units of seconds, rather
than 100ths of seconds, so as to be simpler for agents to
implement (even if they have to implement the 100ths of a
second to comply with implementing sysUpTime in MIB-II[mib-
II].)
NOTE - JmTimeStampTC is defined as an Integer32 so that it can
be used as a value of an attribute, i.e., as a value of the
jmAttributeValueAsInteger object. The TimeStamp textual-
convention defined in SNMPv2-TC [SMIv2-TC] is defined as an
APPLICATION 3 IMPLICIT INTEGER tag, not an Integer32 which is
defined in SNMPv2-SMI [SMIv2-TC] as UNIVERSAL 2 IMPLICIT
INTEGER, so cannot be used in this MIB as one of the values of
jmAttributeValueAsInteger."
SYNTAX INTEGER (0..2147483647)
JmJobSourcePlatformTypeTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The source platform type that can submit jobs to servers or
devices in any of the 3 configurations.
This is a type 2 enumeration. See Section 3.7.1.2. See also
IANA operating-system-names registry."
SYNTAX INTEGER {
other(1),
unknown(2),
sptUNIX(3), -- UNIX
sptOS2(4), -- OS/2
sptPCDOS(5), -- DOS
sptNT(6), -- NT
sptMVS(7), -- MVS
sptVM(8), -- VM
sptOS400(9), -- OS/400
sptVMS(10), -- VMS
sptWindows(11), -- Windows
sptNetWare(12) -- NetWare
}
JmFinishingTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The type of finishing operation.
These values are the same as the enum values of the IPP
'finishings' attribute. See Section 3.7.1.2.
other(1),
Some other finishing operation besides one of the specified
or registered values.
unknown(2),
The finishing is unknown.
none(3),
Perform no finishing.
staple(4),
Bind the document(s) with one or more staples. The exact
number and placement of the staples is site-defined.
punch(5),
Holes are required in the finished document. The exact
number and placement of the holes is site-defined. The
punch specification MAY be satisfied (in a site- and
implementation-specific manner) either by
drilling/punching, or by substituting pre-drilled media.
cover(6),
Select a non-printed (or pre-printed) cover for the
document. This does not supplant the specification of a
printed cover (on cover stock medium) by the document
itself.
bind(7)
Binding is to be applied to the document; the type and
placement of the binding is product-specific.
This is a type 2 enumeration. See Section 3.7.1.2."
SYNTAX INTEGER {
other(1),
unknown(2),
none(3),
staple(4),
punch(5),
cover(6),
bind(7)
}
JmPrintQualityTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Print quality settings.
These values are the same as the enum values of the IPP 'print-
quality' attribute. See Section 3.7.1.2.
This is a type 2 enumeration. See Section 3.7.1.2."
SYNTAX INTEGER {
other(1), -- Not one of the specified or registered
-- values.
unknown(2), -- The actual value is unknown.
draft(3), -- Lowest quality available on the printer.
normal(4), -- Normal or intermediate quality on the
-- printer.
high(5) -- Highest quality available on the printer.
}
JmPrinterResolutionTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Printer resolutions.
Nine octets consisting of two 4-octet SIGNED-INTEGERs followed
by a SIGNED-BYTE. The values are the same as those specified
in the Printer MIB [printmib]. The first SIGNED-INTEGER
contains the value of prtMarkerAddressabilityXFeedDir. The
second SIGNED-INTEGER contains the value of
prtMarkerAddressabilityFeedDir. The SIGNED-BYTE contains the
value of prtMarkerAddressabilityUnit.
Note: the latter value is either 3 (tenThousandsOfInches) or 4
(micrometers) and the addressability is in 10,000 units of
measure. Thus the SIGNED-INTEGERs represent integral values in
either dots-per-inch or dots-per-centimeter.
The syntax is the same as the IPP 'printer-resolution'
attribute. See Section 3.7.1.2."
SYNTAX OCTET STRING (SIZE(9))
JmTonerEconomyTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Toner economy settings.
This is a type 2 enumeration. See Section 3.7.1.2."
SYNTAX INTEGER {
unknown(2), -- unknown.
off(3), -- Off. Normal. Use full toner.
on(4) -- On. Use less toner than normal.
}
JmBooleanTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Boolean true or false value.
This is a type 2 enumeration. See Section 3.7.1.2."
SYNTAX INTEGER {
unknown(2), -- unknown.
false(3), -- FALSE.
true(4) -- TRUE.
}
JmMediumTypeTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Identifies the type of medium.
other(1),
The type is neither one of the values listed in this
specification nor a registered value.
unknown(2),
The type is not known.
stationery(3),
Separately cut sheets of an opaque material.
transparency(4),
Separately cut sheets of a transparent material.
envelope(5),
Envelopes that can be used for conventional mailing
purposes.
envelopePlain(6),
Envelopes that are not preprinted and have no windows.
envelopeWindow(7),
Envelopes that have windows for addressing purposes.
continuousLong(8),
Continuously connected sheets of an opaque material
connected along the long edge.
continuousShort(9),
Continuously connected sheets of an opaque material
connected along the short edge.
tabStock(10),
Media with tabs.
multiPartForm(11),
Form medium composed of multiple layers not pre-attached to
one another; each sheet MAY be drawn separately from an
input source.
labels(12),
Label-stock.
multiLayer(13)
Form medium composed of multiple layers which are pre-
attached to one another, e.g. for use with impact printers.
This is a type 2 enumeration. See Section 3.7.1.2. These enum
values correspond to the keyword name strings of the
prtInputMediaType object in the Printer MIB [print-mib]. There
is no printer description attribute in IPP/1.0 that represents
these values."
SYNTAX INTEGER {
other(1),
unknown(2),
stationery(3),
transparency(4),
envelope(5),
envelopePlain(6),
envelopeWindow(7),
continuousLong(8),
continuousShort(9),
tabStock(10),
multiPartForm(11),
labels(12),
multiLayer(13)
}okay bestie, let's glow up the job collation type 💅
JmJobCollationTypeTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This value is the type of job collation. Implementations that
don't support multiple documents or don't support multiple
copies SHALL NOT support the uncollatedDocuments(5) value.
This is a type 2 enumeration. See Section 3.7.1.2. See also
Section 3.4, entitled 'Monitoring Job Progress'."
SYNTAX INTEGER {
other(1),
unknown(2),
uncollatedSheets(3), -- sheets within each document copy
-- are not collated: 1 1 ..., 2 2 ...,
-- No corresponding value of IPP
-- "multiple-document-handling"
collatedDocuments(4), -- internal collated sheets,
-- documents: A, B, A, B, ...
-- Corresponds to IPP "multiple-
-- document-handling"='separate-
-- documents-collated-copies'
uncollatedDocuments(5) -- internal collated sheets,
-- documents: A, A, ..., B, B, ...
-- Corresponds to IPP "multiple-
-- document-handling"='separate-
-- documents-uncollated-copies'
}So this one is about how the copies get sorted 🧚. The collation value tells you the order of sheets and documents. If your device can't do multiple documents or multiple copies, you're a hard no for uncollatedDocuments(5) 🙅♀️. It's a type 2 enumeration (see Section 3.7.1.2), and the "Monitoring Job Progress" stuff in Section 3.4 is also worth a read. The sheet-order examples are iconic: uncollatedSheets(3) is 1 1 ..., 2 2 ..., collatedDocuments(4) is A, B, A, B, ..., and uncollatedDocuments(5) is A, A, ..., B, B, ... 🦋. The IPP mappings are right there in the comments too.
JmJobSubmissionIDTypeTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Identifies the format type of a job submission ID.
Each job submission ID is a fixed-length, 48-octet printable
US-ASCII [US-ASCII] coded character string containing no
control characters, consisting of the fields defined in section
3.5.1.
This is like a type 2 enumeration. See section 3.7.3."
SYNTAX OCTET STRING(SIZE(1)) -- ASCII '0'-'9', 'A'-'Z', 'a'-'z'Okay, the job submission ID is giving fixed-length. The description says it's a 48-octet printable US-ASCII [US-ASCII] string with no control characters, built from the fields in section 3.5.1 🌸. It's also "like" a type 2 enumeration, so check section 3.7.3 for the vibes. Heads up though: the SYNTAX line only says OCTET STRING(SIZE(1)), with the comment listing '0'-'9', 'A'-'Z', and 'a'-'z'. The description is what spells out the 48-octet length, so keep both in your back pocket 🙈.
JmJobStateTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The current state of the job (pending, processing, completed,
etc.). The following figure shows the normal job state
transitions:
+----> canceled(7)
/
+---> pending(3) -------> processing(5) ------+------> completed(9)
| ^ ^ \
--->+ | | +----> aborted(8)
| v v /
+---> pendingHeld(4) processingStopped(6) ---+
Figure 4 - Normal Job State Transitions
Normally a job progresses from left to right. Other state
transitions are unlikely, but are not forbidden. Not shown are
the transitions to the canceled state from the pending,
pendingHeld, and processingStopped states.
Jobs in the pending, processing, and processingStopped states
are called 'active', while jobs in the pendingHeld, canceled,
aborted, and completed states are called 'inactive'. Jobs
reach one of the three terminal states: completed, canceled, or
aborted, after the jobs have completed all activity, and all
MIB objects and attributes have reached their final values for
the job.
These values are the same as the enum values of the IPP 'job-
state' job attribute. See Section 3.7.1.2.
unknown(2),
The job state is not known, or its state is indeterminate.
pending(3),
The job is a candidate to start processing, but is not yet
processing.
pendingHeld(4),
The job is not a candidate for processing for any number of
reasons but will return to the pending state as soon as the
reasons are no longer present. The job's
jmJobStateReasons1 object and/or jobStateReasonsN (N=2..4)
attributes SHALL indicate why the job is no longer a
candidate for processing. The reasons are represented as
bits in the jmJobStateReasons1 object and/or
jobStateReasonsN (N=2..4) attributes. See the
JmJobStateReasonsNTC (N=1..4) textual convention for the
specification of each reason.
processing(5),
One or more of:
1. the job is using, or is attempting to use, one or
more purely software processes that are analyzing,
creating, or interpreting a PDL, etc.,
2. the job is using, or is attempting to use, one or
more hardware devices that are interpreting a PDL,
making mark on a medium, and/or performing finishing,
such as stapling, etc., OR
3. (configuration 2) the server has made the job ready
for printing, but the output device is not yet printing
it, either because the job hasn't reached the output
device or because the job is queued in the output
device or some other spooler, awaiting the output
device to print it.
When the job is in the processing state, the entire job
state includes the detailed status represented in the
device MIB indicated by the hrDeviceIndex value of the
job's physicalDevice attribute, if the agent implements
such a device MIB.
Implementations MAY, though they NEED NOT, include
additional values in the job's jmJobStateReasons1 object
to indicate the progress of the job, such as adding the
jobPrinting value to indicate when the device is actually
making marks on a medium and/or the processingToStopPoint
value to indicate that the server or device is in the
process of canceling or aborting the job.
processingStopped(6),
The job has stopped while processing for any number of
reasons and will return to the processing state as soon
as the reasons are no longer present.
The job's jmJobStateReasons1 object and/or the job's
jobStateReasonsN (N=2..4) attributes MAY indicate why the
job has stopped processing. For example, if the output
device is stopped, the deviceStopped value MAY be
included in the job's jmJobStateReasons1 object.
NOTE - When an output device is stopped, the device
usually indicates its condition in human readable form
at the device. The management application can obtain
more complete device status remotely by querying the
appropriate device MIB using the job's deviceIndex
attribute(s), if the agent implements such a device MIB
canceled(7),
A client has canceled the job and the server or device
has completed canceling the job AND all MIB objects and
attributes have reached their final values for the job.
While the server or device is canceling the job, the
job's jmJobStateReasons1 object SHOULD contain the
processingToStopPoint value and one of the
canceledByUser, canceledByOperator, or canceledAtDevice
values. The canceledByUser, canceledByOperator, or
canceledAtDevice values remain while the job is in the
canceled state.
aborted(8),
The job has been aborted by the system, usually while the
job was in the processing or processingStopped state and
the server or device has completed aborting the job AND
all MIB objects and attributes have reached their final
values for the job. While the server or device is
aborting the job, the job's jmJobStateReasons1 object MAY
contain the processingToStopPoint and abortedBySystem
values. If implemented, the abortedBySystem value SHALL
remain while the job is in the aborted state.
completed(9)
The job has completed successfully or with warnings or
errors after processing and all of the media have been
successfully stacked in the appropriate output bin(s) AND
all MIB objects and attributes have reached their final
values for the job. The job's jmJobStateReasons1 object
SHOULD contain one of: completedSuccessfully,
completedWithWarnings, or completedWithErrors values.
This is a type 2 enumeration. See Section 3.7.1.2."
SYNTAX INTEGER {
unknown(2),
pending(3),
pendingHeld(4),
processing(5),
processingStopped(6),
canceled(7),
aborted(8),
completed(9)
}this is the main character of the whole MIB 👑 😭 Job state is the vibe check for every print job: pending, processing, completed, and everything in between 💖. Normally a job goes left to right on Figure 4, but other transitions are unlikely (not forbidden though, so stay curious 🔥). Transitions into canceled from pending, pendingHeld, and processingStopped aren't drawn, so don't be shocked.
Active jobs are pending, processing, and processingStopped. Inactive jobs are pendingHeld, canceled, aborted, and completed 🌈. The three terminal states are completed, canceled, and aborted, and they only show up once the job has finished all activity and every MIB object and attribute has its final value ✨. These values mirror the IPP job-state attribute (Section 3.7.1.2).
Quick state tour:
unknown(2): the state is not known or is indeterminate 🧚pending(3): a candidate to start processing, not processing yetpendingHeld(4): not a candidate for some reasons, but it returns to pending once those reasons clear. ThejmJobStateReasons1object and/orjobStateReasonsNattributes must say why, using bits, seeJmJobStateReasonsNTC🔒processing(5): any of three things: software is working on the PDL, hardware is working on it (marking, finishing, stapling, etc.), or the server has the job ready and the device hasn't printed it yet 🖨️. In that state, the device MIB tied to the job'sphysicalDeviceattribute gives the detailed status, if the agent has one.processingStopped(6): stopped while processing, and it will go back to processing when the reasons clear. The reasons may show up injmJobStateReasons1orjobStateReasonsN, likedeviceStoppedfor a stopped device 🍓canceled(7): the client canceled it and the cancel is finished, with everything at final values. While canceling,processingToStopPointplus one ofcanceledByUser,canceledByOperator, orcanceledAtDeviceshould be there, and those last ones stick around in the canceled state 💅aborted(8): the system aborted it, usually from processing or processingStopped, and that's done too.abortedBySystemsticks around in aborted if it's implemented 💀completed(9): finished successfully, with warnings, or with errors, media all stacked, and everything final.completedSuccessfully,completedWithWarnings, orcompletedWithErrorsshould show the outcome 🎀
Literally iconic, and the NOTE about the device MIB is basically "go ask the printer directly" 🫶.
JmAttributeTypeTC ::= TEXTUAL-CONVENTION
JmAttributeTypeTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTIONokay so this one is the type that tells you which attribute you're looking at 👑 it's the identifier that does all the heavy lifting in the jmAttributeTable ✨
the enum numbers are grouped on purpose 🧚 they come in blocks of 20, so new values can get registered later and still land in their logical group. lowkey genius, no cap
values from 230 to 231-1 are reserved for private or experimental use 🔮 that's the same range IPP reserves. they warn you that using these might clash with other implementations, so be careful bestie ⚠️ implementers are encouraged to ask for registration of enum values by following the procedures in Section 3.7.1 🫶
see Section 3.2, 'The Attribute Mechanism', for how this textual-convention works and how it's used in the jmAttributeTable. Section 3.3.8 has the spec for each attribute. the comment after each enum assignment tells you the data type(s) of that attribute 💖
and it's a type 2 enumeration, see Section 3.7.1.2 🎀
SYNTAX INTEGER {
other(1), -- Integer32 (-2..2147483647)
-- AND/OR
-- OCTET STRING(SIZE(0..63))
-- Job State attributes:
jobStateReasons2(3), -- JmJobStateReasons2TC
jobStateReasons3(4), -- JmJobStateReasons3TC
jobStateReasons4(5), -- JmJobStateReasons4TC
processingMessage(6), -- JmUTF8StringTC (SIZE(0..63))
processingMessageNaturalLangTag(7),
-- OCTET STRING(SIZE(0..63))
jobCodedCharSet(8), -- CodedCharSet
jobNaturalLanguageTag(9), -- OCTET STRING(SIZE(0..63))
-- Job Identification attributes:
jobURI(20), -- OCTET STRING(SIZE(0..63))
jobAccountName(21), -- OCTET STRING(SIZE(0..63))
serverAssignedJobName(22), -- JmJobStringTC (SIZE(0..63))
jobName(23), -- JmJobStringTC (SIZE(0..63))
jobServiceTypes(24), -- JmJobServiceTypesTC
jobSourceChannelIndex(25), -- Integer32 (0..2147483647)
jobSourcePlatformType(26), -- JmJobSourcePlatformTypeTC
submittingServerName(27), -- JmJobStringTC (SIZE(0..63))
submittingApplicationName(28), -- JmJobStringTC (SIZE(0..63))
jobOriginatingHost(29), -- JmJobStringTC (SIZE(0..63))
deviceNameRequested(30), -- JmJobStringTC (SIZE(0..63))
queueNameRequested(31), -- JmJobStringTC (SIZE(0..63))
physicalDevice(32), -- hrDeviceIndex
-- AND/OR
-- JmUTF8StringTC (SIZE(0..63))
numberOfDocuments(33), -- Integer32 (-2..2147483647)
fileName(34), -- JmJobStringTC (SIZE(0..63))
documentName(35), -- JmJobStringTC (SIZE(0..63))
jobComment(36), -- JmJobStringTC (SIZE(0..63))
documentFormatIndex(37), -- Integer32 (0..2147483647)
documentFormat(38), -- PrtInterpreterLangFamilyTC
-- AND/OR
-- OCTET STRING(SIZE(0..63))
-- Job Parameter attributes:
jobPriority(50), -- Integer32 (-2..100)
jobProcessAfterDateAndTime(51), -- DateAndTime (SNMPv2-TC)
jobHold(52), -- JmBooleanTC
jobHoldUntil(53), -- JmJobStringTC (SIZE(0..63))
outputBin(54), -- Integer32 (0..2147483647)
-- AND/OR
-- JmJobStringTC (SIZE(0..63))
sides(55), -- Integer32 (-2..2)
finishing(56), -- JmFinishingTC
-- Image Quality attributes:
printQualityRequested(70), -- JmPrintQualityTC
printQualityUsed(71), -- JmPrintQualityTC
printerResolutionRequested(72), -- JmPrinterResolutionTC
printerResolutionUsed(73), -- JmPrinterResolutionTC
tonerEcomonyRequested(74), -- JmTonerEconomyTC
tonerEcomonyUsed(75), -- JmTonerEconomyTC
tonerDensityRequested(76), -- Integer32 (-2..100)
tonerDensityUsed(77), -- Integer32 (-2..100)
-- Job Progress attributes:
jobCopiesRequested(90), -- Integer32 (-2..2147483647)
jobCopiesCompleted(91), -- Integer32 (-2..2147483647)
documentCopiesRequested(92), -- Integer32 (-2..2147483647)
documentCopiesCompleted(93), -- Integer32 (-2..2147483647)
jobKOctetsTransferred(94), -- Integer32 (-2..2147483647)
sheetCompletedCopyNumber(95), -- Integer32 (-2..2147483647)
sheetCompletedDocumentNumber(96),
-- Integer32 (-2..2147483647)
jobCollationType(97), -- JmJobCollationTypeTC
-- Impression attributes:
impressionsSpooled(110), -- Integer32 (-2..2147483647)
impressionsSentToDevice(111), -- Integer32 (-2..2147483647)
impressionsInterpreted(112), -- Integer32 (-2..2147483647)
impressionsCompletedCurrentCopy(113),
-- Integer32 (-2..2147483647)
fullColorImpressionsCompleted(114),
-- Integer32 (-2..2147483647)
highlightColorImpressionsCompleted(115),
-- Integer32 (-2..2147483647)
-- Page attributes:
pagesRequested(130), -- Integer32 (-2..2147483647)
pagesCompleted(131), -- Integer32 (-2..2147483647)
pagesCompletedCurrentCopy(132), -- Integer32 (-2..2147483647)
-- Sheet attributes:
sheetsRequested(150), -- Integer32 (-2..2147483647)
sheetsCompleted(151), -- Integer32 (-2..2147483647)
sheetsCompletedCurrentCopy(152),-- Integer32 (-2..2147483647)
-- Resource attributes:
mediumRequested(170), -- JmMediumTypeTC
-- AND/OR
-- JmJobStringTC (SIZE(0..63))
mediumConsumed(171), -- Integer32 (-2..2147483647)
-- AND
-- JmJobStringTC (SIZE(0..63))
colorantRequested(172), -- Integer32 (-2..2147483647)
-- AND/OR
-- JmJobStringTC (SIZE(0..63))
colorantConsumed(173), -- Integer32 (-2..2147483647)
-- AND/OR
-- JmJobStringTC (SIZE(0..63))
mediumTypeConsumed(174), -- Integer32 (-2..2147483647)
-- AND
-- JmJobStringTC (SIZE(0..63))
mediumSizeConsumed(175), -- Integer32 (-2..2147483647)
-- AND
-- JmJobStringTC (SIZE(0..63))
-- Time attributes:
jobSubmissionToServerTime(190), -- JmTimeStampTC
-- AND/OR
-- DateAndTime
jobSubmissionTime(191), -- JmTimeStampTC
-- AND/OR
-- DateAndTime
jobStartedBeingHeldTime(192), -- JmTimeStampTC
-- AND/OR
-- DateAndTime
jobStartedProcessingTime(193), -- JmTimeStampTC
-- AND/OR
-- DateAndTime
jobCompletionTime(194), -- JmTimeStampTC
-- AND/OR
-- DateAndTime
jobProcessingCPUTime(195) -- Integer32 (-2..2147483647)
}JmJobServiceTypesTC ::= TEXTUAL-CONVENTION
JmJobServiceTypesTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTIONthis one tells you what kind(s) of service a job was submitted to 🖨️ print, fax, scan, the works. it's bit-encoded, which means you can mix service types together for more general or arbitrary services 🌈 like a service that has more than one destination, or only a source, or only a destination
quick example bestie: a job that scans, faxOut, and prints the same document would set three bits, 0x8 + 0x20 + 0x4, which adds up to 0x2C ✨ very math, very cute
whether this gets set from a job attribute the submission client sent, or by the server or device that receives the job, depends on the job submission protocol 💅 either way, the agent SHALL return a non-zero value here so the job's type is actually known 💖
the whole point is letting a requester filter out jobs they don't care about 🙈 like a printer operator who MAY only be interested in jobs that include printing. that's why this lives in the job identification category 🧚
the service component types and their bit values (in hexadecimal) are:
other 0x1
The job contains some instructions that are not one of the
identified types.
unknown 0x2
The job contains some instructions whose type is unknown to
the agent.
print 0x4
The job contains some instructions that specify printing
scan 0x8
The job contains some instructions that specify scanning
faxIn 0x10
The job contains some instructions that specify receive fax
faxOut 0x20
The job contains some instructions that specify sending fax
getFile 0x40
The job contains some instructions that specify accessing
files or documents
putFile 0x80
The job contains some instructions that specify storing
files or documents
mailList 0x100
The job contains some instructions that specify
distribution of documents using an electronic mail system.these bit definitions are basically a type 2 enum, except combinations of them MAY be used together 🫶 see section 3.7.1.2 🎀
SYNTAX INTEGER (0..2147483647) -- 31 bits, all but sign bitokay bestie, the job state reasons are basically bitfields with main character energy 🎀 Each one is an INTEGER from 0 to 2147483647, so 31 bits, all but the sign bit 💅
JmJobStateReasons1TC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The JmJobStateReasonsNTC (N=1..4) textual-conventions are used
with the jmJobStateReasons1 object and jobStateReasonsN
(N=2..4), respectively, to provide additional information
regarding the current jmJobState object value. These values
MAY be used with any job state or states for which the reason
makes sense. See section 3.3.9.1 for the specification of each
bit value defined for use with the JmJobStateReasons1TC.
These bit definitions are the equivalent of a type 2 enum
except that combinations of bits may be used together. See
section 3.7.1.2."
SYNTAX INTEGER (0..2147483647) -- 31 bits, all but sign bit
JmJobStateReasons2TC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This textual-convention is used with the jobStateReasons2
attribute to provides additional information regarding the
jmJobState object. See section 3.3.9.2 for the specification
of JmJobStateReasons2TC. See section 3.3.9.1 for the
description under JmJobStateReasons1TC for additional
information that applies to all reasons.
These bit definitions are the equivalent of a type 2 enum
except that combinations of them may be used together. See
section 3.7.1.2."
SYNTAX INTEGER (0..2147483647) -- 31 bits, all but sign bit
JmJobStateReasons3TC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This textual-convention is used with the jobStateReasons3
attribute to provides additional information regarding the
jmJobState object. See section 3.3.9.3 for the specification
of JmJobStateReasons3TC. See section 3.3.9.1 for the
description under JmJobStateReasons1TC for additional
information that applies to all reasons.
These bit definitions are the equivalent of a type 2 enum
except that combinations of them may be used together. See
section 3.7.1.2. "
SYNTAX INTEGER (0..2147483647) -- 31 bits, all but sign bit
JmJobStateReasons4TC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This textual-convention is used in the jobStateReasons4
attribute to provides additional information regarding the
jmJobState object. See section 3.3.9.4 for the specification
of JmJobStateReasons4TC. See section 3.3.9.1 for the
description under JmJobStateReasons1TC for additional
information that applies to all reasons.
These bit definitions are the equivalent of a type 2 enum
except that combinations of them may be used together. See
section 3.7.1.2."
SYNTAX INTEGER (0..2147483647) -- 31 bits, all but sign bitNow the good stuff: the General Group 🧚 The General Group is the one that's MANDATORY, and it's all about each job set (queue) as a whole, not each individual job ✨
jobmonMIBObjects OBJECT IDENTIFIER ::= { jobmonMIB 1 }
-- The General Group (MANDATORY)
-- The jmGeneralGroup consists entirely of the jmGeneralTable.
jmGeneral OBJECT IDENTIFIER ::= { jobmonMIBObjects 1 }
jmGeneralTable OBJECT-TYPE
SYNTAX SEQUENCE OF JmGeneralEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The jmGeneralTable consists of information of a general nature
that are per-job-set, but are not per-job. See Section 2
entitled 'Terminology and Job Model' for the definition of a
job set.
The MANDATORY-GROUP macro specifies that this group is
MANDATORY."
::= { jmGeneral 1 }
jmGeneralEntry OBJECT-TYPE
SYNTAX JmGeneralEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a job set (queue).
An entry SHALL exist in this table for each job set."
INDEX { jmGeneralJobSetIndex }
::= { jmGeneralTable 1 }
JmGeneralEntry ::= SEQUENCE {
jmGeneralJobSetIndex Integer32 (1..32767),
jmGeneralNumberOfActiveJobs Integer32 (0..2147483647),
jmGeneralOldestActiveJobIndex Integer32 (0..2147483647),
jmGeneralNewestActiveJobIndex Integer32 (0..2147483647),
jmGeneralJobPersistence Integer32 (15..2147483647),
jmGeneralAttributePersistence Integer32 (15..2147483647),
jmGeneralJobSetName JmUTF8StringTC (SIZE(0..63))
}
jmGeneralJobSetIndex OBJECT-TYPE
SYNTAX Integer32 (1..32767)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value for each job set in this MIB. The jmJobTable
and jmAttributeTable tables have this same index as their
primary index.
The value(s) of the jmGeneralJobSetIndex SHALL be persistent
across power cycles, so that clients that have retained
jmGeneralJobSetIndex values will access the same job sets upon
subsequent power-up.
An implementation that has only one job set, such as a printer
with a single queue, SHALL hard code this object with the value
1.
See Section 2 entitled 'Terminology and Job Model' for the
definition of a job set.
Corresponds to the first index in jmJobTable and
jmAttributeTable."
::= { jmGeneralEntry 1 }
jmGeneralNumberOfActiveJobs OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current number of 'active' jobs in the jmJobIDTable,
jmJobTable, and jmAttributeTable, i.e., the total number of
jobs that are in the pending, processing, or processingStopped
states. See the JmJobStateTC textual-convention for the exact
specification of the semantics of the job states."
DEFVAL { 0 } -- no jobs
::= { jmGeneralEntry 2 }
jmGeneralOldestActiveJobIndex OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The jmJobIndex of the oldest job that is still in one of the
'active' states (pending, processing, or processingStopped).
In other words, the index of the 'active' job that has been in
the job tables the longest.
If there are no active jobs, the agent SHALL set the value of
this object to 0.
See Section 3.2 entitled 'The Job Tables and the Oldest Active
and Newest Active Indexes' for a description of the usage of
this object."
DEFVAL { 0 } -- no active jobs
::= { jmGeneralEntry 3 }
jmGeneralNewestActiveJobIndex OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The jmJobIndex of the newest job that is in one of the
'active' states (pending, processing, or processingStopped).
In other words, the index of the 'active' job that has been
most recently added to the job tables.
When all jobs become 'inactive', i.e., enter the pendingHeld,
completed, canceled, or aborted states, the agent SHALL set the
value of this object to 0.
See Section 3.2 entitled 'The Job Tables and the Oldest Active
and Newest Active Indexes' for a description of the usage of
this object."
DEFVAL { 0 } -- no active jobs
::= { jmGeneralEntry 4 }
jmGeneralJobPersistence OBJECT-TYPE
SYNTAX Integer32 (15..2147483647)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum time in seconds for this instance of the Job Set
that an entry SHALL remain in the jmJobIDTable and jmJobTable
after processing has completed, i.e., the minimum time in
seconds starting when the job enters the completed, canceled,
or aborted state.
Configuring this object is implementation-dependent.
This value SHALL be equal to or greater than the value of
jmGeneralAttributePersistence. This value SHOULD be at least
60 which gives a monitoring or accounting application one
minute in which to poll for job data."
DEFVAL { 60 } -- one minute
::= { jmGeneralEntry 5 }
jmGeneralAttributePersistence OBJECT-TYPE
SYNTAX Integer32 (15..2147483647)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum time in seconds for this instance of the Job Set
that an entry SHALL remain in the jmAttributeTable after
processing has completed , i.e., the time in seconds starting
when the job enters the completed, canceled, or aborted state.
Configuring this object is implementation-dependent.
This value SHOULD be at least 60 which gives a monitoring or
accounting application one minute in which to poll for job
data."
DEFVAL { 60 } -- one minute
::= { jmGeneralEntry 6 }
jmGeneralJobSetName OBJECT-TYPE
SYNTAX JmUTF8StringTC (SIZE(0..63))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The human readable name of this job set assigned by the system
administrator (by means outside of this MIB). Typically, this
name SHOULD be the name of the job queue. If a server or
device has only a single job set, this object can be the
administratively assigned name of the server or device itself.
This name does not need to be unique, though each job set in a
single Job Monitoring MIB SHOULD have distinct names.
NOTE - If the job set corresponds to a single printer and the
Printer MIB is implemented, this value SHOULD be the same as
the prtGeneralPrinterName object in the draft Printer MIB
[print-mib-draft]. If the job set corresponds to an IPP
Printer, this value SHOULD be the same as the IPP 'printer-
name' Printer attribute.
NOTE - The purpose of this object is to help the user of the
job monitoring application distinguish between several job sets
in implementations that support more than one job set.
See the OBJECT compliance macro for the minimum maximum length
required for conformance."
DEFVAL { ''H } -- empty string
::= { jmGeneralEntry 7 }
-- The Job ID Group (MANDATORY)
-- The jmJobIDGroup consists entirely of the jmJobIDTable.
jmJobID OBJECT IDENTIFIER ::= { jobmonMIBObjects 2 }
jmJobIDTable OBJECT-TYPE
SYNTAX SEQUENCE OF JmJobIDEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The jmJobIDTable provides a correspondence map (1) between the
job submission ID that a client uses to refer to a job and (2)
the jmGeneralJobSetIndex and jmJobIndex that the Job Monitoring
MIB agent assigned to the job and that are used to access the
job in all of the other tables in the MIB. If a monitoring
application already knows the jmGeneralJobSetIndex and the
jmJobIndex of the job it is querying, that application NEED NOT
use the jmJobIDTable.
The MANDATORY-GROUP macro specifies that this group is
MANDATORY."
::= { jmJobID 1 }Quick vibe check on the jmJobIDTable: it's the map from a client's job submission ID to the job set index and job index the agent handed out 🦋 If your monitoring app already knows those two indexes, it doesn't need the table at all, and the spec says so in capitals: NEED NOT 🙈
okay so the jmJobIDEntry is basically the matchmaker 💘, mapping a jmJobSubmissionID to a jmGeneralJobSetIndex and a jmJobIndex. full main character energy for the whole table 🎀
jmJobIDEntry OBJECT-TYPE
SYNTAX JmJobIDEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The map from (1) the jmJobSubmissionID to (2) the
jmGeneralJobSetIndex and jmJobIndex.
An entry SHALL exist in this table for each job currently known
to the agent for all job sets and job states. There MAY be
more than one jmJobIDEntry that maps to a single job. This
many to one mapping can occur when more than one network entity
along the job submission path supplies a job submission ID.
See Section 3.5. However, each job SHALL appear once and in
one and only one job set."
INDEX { jmJobSubmissionID }
::= { jmJobIDTable 1 }
JmJobIDEntry ::= SEQUENCE {
jmJobSubmissionID OCTET STRING(SIZE(48)),
jmJobIDJobSetIndex Integer32 (0..32767),
jmJobIDJobIndex Integer32 (0..2147483647)
}so every job gets one row per table entry 🦋 but a single job can have more than one jmJobIDEntry if lots of network entities along the path each hand over their own submission ID. 💅 the only hard rule here is that each job lives in one and only one job set 🌸 no double dipping!!
the jmJobSubmissionID is the ID tea ☕ it's a quasi-unique 48-octet string that's fixed-length, which is honestly so clean. multiple formats exist and they're all registered, and the agent can slap on its own ID if the requester didn't bring one 🫶
jmJobSubmissionID OBJECT-TYPE
SYNTAX OCTET STRING(SIZE(48))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A quasi-unique 48-octet fixed-length string ID which
identifies the job within a particular client-server
environment. There are multiple formats for the
jmJobSubmissionID. Each format SHALL be uniquely identified.
See the JmJobSubmissionIDTypeTC textual convention. Each
format SHALL be registered using the procedures of a type 2
enum. See section 3.7.3 entitled: 'PWG Registration of Job
Submission Id Formats'.
If the requester (client or server) does not supply a job
submission ID in the job submission protocol, then the
recipient (server or device) SHALL assign a job submission ID
using any of the standard formats that have been reserved for
agents and adding the final 8 octets to distinguish the ID from
others submitted from the same requester.
The monitoring application, whether in the client or running
separately, MAY use the job submission ID to help identify
which jmJobIndex was assigned by the agent, i.e., in which row
the job information is in the other tables.
NOTE - fixed-length is used so that a management application
can use a shortened GetNext varbind (in SNMPv1 and SNMPv2) in
order to get the next submission ID, disregarding the remainder
of the ID in order to access jobs independent of the trailing
identifier part, e.g., to get all jobs submitted by a
particular jmJobOwner or submitted from a particular MAC
address.
See the JmJobSubmissionIDTypeTC textual convention.
See APPENDIX B - Support of Job Submission Protocols."
::= { jmJobIDEntry 1 }ngl the NOTE is my favourite bit 🙈 the fixed length is what lets a management app do a shortened GetNext varbind (in SNMPv1 and SNMPv2) to hop straight to the next submission ID and ignore the trailing part. so you can pull up every job from a certain jmJobOwner or MAC address, iykyk 🧚
jmJobIDJobSetIndex OBJECT-TYPE
SYNTAX Integer32 (0..32767)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the value of the jmGeneralJobSetIndex for
the job with the jmJobSubmissionID value, i.e., the job set
index of the job set in which the job was placed when that
server or device accepted the job. This 16-bit value in
combination with the jmJobIDJobIndex value permits the
management application to access the other tables to obtain the
job-specific objects for this job.
See jmGeneralJobSetIndex in the jmGeneralTable."
DEFVAL { 0 } -- 0 indicates no job set index
::= { jmJobIDEntry 2 }
jmJobIDJobIndex OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the value of the jmJobIndex for the job
with the jmJobSubmissionID value, i.e., the job index for the
job when the server or device accepted the job. This value, in
combination with the jmJobIDJobSetIndex value, permits the
management application to access the other tables to obtain the
job-specific objects for this job.
See jmJobIndex in the jmJobTable."
DEFVAL { 0 } -- 0 indicates no jmJobIndex value.
::= { jmJobIDEntry 3 }so the jmJobIDJobSetIndex and jmJobIDJobIndex are the pair 👯♀️ together they're the key that unlocks the other tables. the set index is the 16-bit one, and 0 just means "no job set index" 💀
The Job Group (MANDATORY) 🎀
-- The Job Group (MANDATORY)
-- The jmJobGroup consists entirely of the jmJobTable.
jmJob OBJECT IDENTIFIER ::= { jobmonMIBObjects 3 }
jmJobTable OBJECT-TYPE
SYNTAX SEQUENCE OF JmJobEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The jmJobTable consists of basic job state and status
information for each job in a job set that (1) monitoring
applications need to be able to access in a single SNMP Get
operation, (2) that have a single value per job, and (3) that
SHALL always be implemented.
The MANDATORY-GROUP macro specifies that this group is
MANDATORY."
::= { jmJob 1 }
jmJobEntry OBJECT-TYPE
SYNTAX JmJobEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Basic per-job state and status information.
An entry SHALL exist in this table for each job, no matter what
the state of the job is. Each job SHALL appear in one and only
one job set.
See Section 3.2 entitled 'The Job Tables'."
INDEX { jmGeneralJobSetIndex, jmJobIndex }
::= { jmJobTable 1 }
JmJobEntry ::= SEQUENCE {
jmJobIndex Integer32 (1..2147483647),
jmJobState JmJobStateTC,
jmJobStateReasons1 JmJobStateReasons1TC,
jmNumberOfInterveningJobs Integer32 (-2..2147483647),
jmJobKOctetsPerCopyRequested Integer32 (-2..2147483647),
jmJobKOctetsProcessed Integer32 (-2..2147483647),
jmJobImpressionsPerCopyRequested Integer32 (-2..2147483647),
jmJobImpressionsCompleted Integer32 (-2..2147483647),
jmJobOwner JmJobStringTC (SIZE(0..63))
}this is the MANDATORY group, so no skipping it 🙅♀️ the jmJobTable is where the basic state and status for each job lives, the stuff monitoring apps need in a single SNMP Get. one row per job, always, whatever state it's in 💖
jmJobIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The sequential, monatonically increasing identifier index for
the job generated by the server or device when that server or
device accepted the job. This index value permits the
management application to access the other tables to obtain the
job-specific row entries.
See Section 3.2 entitled 'The Job Tables and the Oldest Active
and Newest Active Indexes'.
See Section 3.5 entitled 'Job Identification'.
See also jmGeneralNewestActiveJobIndex for the largest value of
jmJobIndex.
See JmJobSubmissionIDTypeTC for a limit on the size of this
index if the agent represents it as an 8-digit decimal number."
::= { jmJobEntry 1 }
jmJobState OBJECT-TYPE
SYNTAX JmJobStateTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current state of the job (pending, processing, completed,
etc.). Agents SHALL implement only those states which are
appropriate for the particular implementation. However,
management applications SHALL be prepared to receive all the
standard job states.
The final value for this object SHALL be one of: completed,
canceled, or aborted. The minimum length of time that the
agent SHALL maintain MIB data for a job in the completed,
canceled, or aborted state before removing the job data from
the jmJobIDTable and jmJobTable is specified by the value of
the jmGeneralJobPersistence object."
DEFVAL { unknown } -- default is unknown
::= { jmJobEntry 2 }
jmJobStateReasons1 OBJECT-TYPE
SYNTAX JmJobStateReasons1TC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Additional information about the job's current state, i.e.,
information that augments the value of the job's jmJobState
object.
Implementation of any reason values is OPTIONAL, but an agent
SHOULD return any reason information available. These values
MAY be used with any job state or states for which the reason
makes sense. Since the Job State Reasons will be more dynamic
than the Job State, it is recommended that a job monitoring
application read this object every time jmJobState is read.
When the agent cannot provide a reason for the current state of
the job, the value of the jmJobStateReasons1 object and
jobStateReasonsN attributes SHALL be 0.
The jobStateReasonsN (N=2..4) attributes provide further
additional information about the job's current state."
DEFVAL { 0 } -- no reasons
::= { jmJobEntry 3 }jmJobIndex is the sequential, monatonically (sic, the original has that typo 😭) increasing ID the server gives each job when it accepts it. jmJobState is the vibe check: pending, processing, completed, all of it 🔥 and jmJobStateReasons1 is the extra context that explains why the state is what it is. reasons are OPTIONAL to implement, but the agent should send any reason it has, and if it has none, the value is 0 🫠
jmNumberOfInterveningJobs OBJECT-TYPE
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of jobs that are expected to complete processing
before this job has completed processing according to the
implementation's queuing algorithm, if no other jobs were to be
submitted. In other words, this value is the job's queue
position. The agent SHALL return a value of 0 for this
attribute when the job is the next job to complete processing
(or has completed processing)."
DEFVAL { 0 } -- default is no intervening jobs.
::= { jmJobEntry 4 }
jmJobKOctetsPerCopyRequested OBJECT-TYPE
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total size in K (1024) octets of the document(s) being
requested to be processed in the job. The agent SHALL round
the actual number of octets up to the next highest K. Thus 0
octets is represented as '0', 1-1024 octets is represented as
'1', 1025-2048 is represented as '2', etc.
In computing this value, the server/device SHALL NOT include
the multiplicative factors contributed by (1) the number of
document copies, and (2) the number of job copies, independent
of whether the device can process multiple copies of the job or
document without making multiple passes over the job or
document data and independent of whether the output is collated
or not. Thus the server/device computation is independent of
the implementation and indicates the size of the document(s)
measured in K octets independent of the number of copies."
DEFVAL { -2 } -- the default is unknown(-2)
::= { jmJobEntry 5 }jmNumberOfInterveningJobs is basically your queue position 🧚 zero means you're up next (or already done) 🎀 and jmJobKOctetsPerCopyRequested measures the document size in K (1024) octets, rounded up, and it does not count copies, so it's the size of the doc, not the size times how many copies you asked for 🌸
okay bestie, now we're getting into the job progress counters 📊✨ these are literally how the job tracks its own glow-up 💅
jmJobKOctetsProcessed OBJECT-TYPE
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets processed by the server or device
measured in units of K (1024) octets so far. The agent SHALL
round the actual number of octets processed up to the next
higher K. Thus 0 octets is represented as '0', 1-1024 octets
is represented as '1', 1025-2048 octets is '2', etc. For
printing devices, this value is the number interpreted by the
page description language interpreter rather than what has been
marked on media.
For implementations where multiple copies are produced by the
interpreter with only a single pass over the data, the final
value SHALL be equal to the value of the
jmJobKOctetsPerCopyRequested object. For implementations where
multiple copies are produced by the interpreter by processing
the data for each copy, the final value SHALL be a multiple of
the value of the jmJobKOctetsPerCopyRequested object.
NOTE - See the impressionsCompletedCurrentCopy and
pagesCompletedCurrentCopy attributes for attributes that are
reset on each document copy.
NOTE - The jmJobKOctetsProcessed object can be used with the
jmJobKOctetsPerCopyRequested object to provide an indication of
the relative progress of the job, provided that the
multiplicative factor is taken into account for some
implementations of multiple copies."
DEFVAL { 0 } -- default is no octets processed.
::= { jmJobEntry 6 }
jmJobImpressionsPerCopyRequested OBJECT-TYPE
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total size in number of impressions of the document(s)
submitted.
In computing this value, the server/device SHALL NOT include
the multiplicative factors contributed by (1) the number of
document copies, and (2) the number of job copies, independent
of whether the device can process multiple copies of the job or
document without making multiple passes over the job or
document data and independent of whether the output is collated
or not. Thus the server/device computation is independent of
the implementation and reflects the size of the document(s)
measured in impressions independent of the number of copies.
See the definition of the term 'impression' in Section 2."
DEFVAL { -2 } -- default is unknown(-2)
::= { jmJobEntry 7 }
jmJobImpressionsCompleted OBJECT-TYPE
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of impressions completed for this job so far.
For printing devices, the impressions completed includes
interpreting, marking, and stacking the output. For other
types of job services, the number of impressions completed
includes the number of impressions processed.
NOTE - See the impressionsCompletedCurrentCopy and
pagesCompletedCurrentCopy attributes for attributes that are
reset on each document copy.
NOTE - The jmJobImpressionsCompleted object can be used with
the jmJobImpressionsPerCopyRequested object to provide an
indication of the relative progress of the job, provided that
the multiplicative factor is taken into account for some
implementations of multiple copies.
See the definition of the term 'impression' in Section 2 and
the counting example in Section 3.4 entitled 'Monitoring Job
Progress'."
DEFVAL { 0 } -- default is no octets
::= { jmJobEntry 8 }
jmJobOwner OBJECT-TYPE
SYNTAX JmJobStringTC (SIZE(0..63))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The coded character set name of the user that submitted the
job. The method of assigning this user name will be system
and/or site specific but the method MUST ensure that the name
is unique to the network that is visible to the client and
target device.
This value SHOULD be the most authenticated name of the user
submitting the job.
See the OBJECT compliance macro for the minimum maximum length
required for conformance."
DEFVAL { ''H } -- default is empty string
::= { jmJobEntry 9 }
-- The Attribute Group (MANDATORY)
-- The jmAttributeGroup consists entirely of the jmAttributeTable.
--
-- Implementation of the objects in this group is MANDATORY.
-- See Section 3.1 entitled 'Conformance Considerations'.
-- An agent SHALL implement any attribute if (1) the server or device
-- supports the functionality represented by the attribute and (2) the
-- information is available to the agent.
jmAttribute OBJECT IDENTIFIER ::= { jobmonMIBObjects 4 }
jmAttributeTable OBJECT-TYPE
SYNTAX SEQUENCE OF JmAttributeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The jmAttributeTable SHALL contain attributes of the job and
document(s) for each job in a job set. Instead of allocating
distinct objects for each attribute, each attribute is
represented as a separate row in the jmAttributeTable.
The MANDATORY-GROUP macro specifies that this group is
MANDATORY. An agent SHALL implement any attribute if (1) the
server or device supports the functionality represented by the
attribute and (2) the information is available to the agent. "
::= { jmAttribute 1 }
jmAttributeEntry OBJECT-TYPE
SYNTAX JmAttributeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Attributes representing information about the job and
document(s) or resources required and/or consumed.
Each entry in the jmAttributeTable is a per-job entry with an
extra index for each type of attribute (jmAttributeTypeIndex)
that a job can have and an additional index
(jmAttributeInstanceIndex) for those attributes that can have
multiple instances per job. The jmAttributeTypeIndex object
SHALL contain an enum type that indicates the type of attribute
(see the JmAttributeTypeTC textual-convention). The value of
the attribute SHALL be represented in either the
jmAttributeValueAsInteger or jmAttributeValueAsOctets objects,
and/or both, as specified in the JmAttributeTypeTC textual-
convention.
The agent SHALL create rows in the jmAttributeTable as the
server or device is able to discover the attributes either from
the job submission protocol itself or from the document PDL.
As the documents are interpreted, the interpreter MAY discover
additional attributes and so the agent adds additional rows to
this table. As the attributes that represent resources are
actually consumed, the usage counter contained in the
jmAttributeValueAsInteger object is incremented according to
the units indicated in the description of the JmAttributeTypeTC
enum.
The agent SHALL maintain each row in the jmAttributeTable for
at least the minimum time after a job completes as specified by
the jmGeneralAttributePersistence object.
Zero or more entries SHALL exist in this table for each job in
a job set.
See Section 3.3 entitled 'The Attribute Mechanism' for a
description of the jmAttributeTable."
INDEX { jmGeneralJobSetIndex, jmJobIndex, jmAttributeTypeIndex,
jmAttributeInstanceIndex }
::= { jmAttributeTable 1 }
JmAttributeEntry ::= SEQUENCE {
jmAttributeTypeIndex JmAttributeTypeTC,
jmAttributeInstanceIndex Integer32 (1..32767),
jmAttributeValueAsInteger Integer32 (-2..2147483647),
jmAttributeValueAsOctets OCTET STRING(SIZE(0..63))
}
jmAttributeTypeIndex OBJECT-TYPE
SYNTAX JmAttributeTypeTC
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of attribute that this row entry represents.
The type MAY identify information about the job or document(s)
or MAY identify a resource required to process the job before
the job start processing and/or consumed by the job as the job
is processed.
Examples of job attributes (i.e., apply to the job as a whole)
that have only one instance per job include:
jobCopiesRequested(90), documentCopiesRequested(92),
jobCopiesCompleted(91), documentCopiesCompleted(93), while
examples of job attributes that may have more than one instance
per job include: documentFormatIndex(37), and
documentFormat(38).
Examples of document attributes (one instance per document)
include: fileName(34), and documentName(35).
Examples of required and consumed resource attributes include:
pagesRequested(130), mediumRequested(170), pagesCompleted(131),
and mediumConsumed(171), respectively."
::= { jmAttributeEntry 1 }
jmAttributeInstanceIndex OBJECT-TYPE
SYNTAX Integer32 (1..32767)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A running 16-bit index of the attributes of the same type for
each job. For those attributes with only a single instance per
job, this index value SHALL be 1. For those attributes that
are a single value per document, the index value SHALL be the
document number, starting with 1 for the first document in the
job. Jobs with only a single document SHALL use the index
value of 1. For those attributes that can have multiple values
per job or per document, such as documentFormatIndex(37) or
documentFormat(38), the index SHALL be a running index for the
job as a whole, starting at 1."
::= { jmAttributeEntry 2 }the attribute table is giving main character energy 🎀 every job gets its own little row of receipts 🧾💜
okay the attribute values are where this MIB gets extra detailed 😭 but I'm keeping the code exactly as written so nothing gets lost 🫶
jmAttributeValueAsInteger OBJECT-TYPE
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The integer value of the attribute. The value of the
attribute SHALL be represented as an integer if the enum
description in the JmAttributeTypeTC textual-convention
definition has the tag: 'INTEGER:'.
Depending on the enum definition, this object value MAY be an
integer, a counter, an index, or an enum, depending on the
jmAttributeTypeIndex value. The units of this value are
specified in the enum description.
For those attributes that are accumulating job consumption as
the job is processed as specified in the JmAttributeTypeTC
textual-convention, SHALL contain the final value after the job
completes processing, i.e., this value SHALL indicate the total
usage of this resource made by the job.
A monitoring application is able to copy this value to a
suitable longer term storage for later processing as part of an
accounting system.
Since the agent MAY add attributes representing resources to
this table while the job is waiting to be processed or being
processed, which can be a long time before any of the resources
are actually used, the agent SHALL set the value of the
jmAttributeValueAsInteger object to 0 for resources that the
job has not yet consumed.
Attributes for which the concept of an integer value is
meaningless, such as fileName(34), jobName, and
processingMessage, do not have the 'INTEGER:' tag in the
JmAttributeTypeTC definition and so an agent SHALL always
return a value of '-1' to indicate 'other' for the value of the
jmAttributeValueAsInteger object for these attributes.
For attributes which do have the 'INTEGER:' tag in the
JmAttributeTypeTC definition, if the integer value is not (yet)
known, the agent either (1) SHALL not materialize the row in
the jmAttributeTable until the value is known or (2) SHALL
return a '-2' to represent an 'unknown' counting integer value,
a '0' to represent an 'unknown' index value, and a '2' to
represent an 'unknown(2)' enum value."
DEFVAL { -2 } -- default value is unknown(-2)
::= { jmAttributeEntry 3 }
jmAttributeValueAsOctets OBJECT-TYPE
SYNTAX OCTET STRING(SIZE(0..63))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The octet string value of the attribute. The value of the
attribute SHALL be represented as an OCTET STRING if the enum
description in the JmAttributeTypeTC textual-convention
definition has the tag: 'OCTETS:'.
Depending on the enum definition, this object value MAY be a
coded character set string (text), such as 'JmUTF8StringTC', or
a binary octet string, such as 'DateAndTime'.
Attributes for which the concept of an octet string value is
meaningless, such as pagesCompleted, do not have the tag
'OCTETS:' in the JmAttributeTypeTC definition and so the agent
SHALL always return a zero length string for the value of the
jmAttributeValueAsOctets object.
For attributes which do have the 'OCTETS:' tag in the
JmAttributeTypeTC definition, if the OCTET STRING value is not
(yet) known, the agent either SHALL NOT materialize the row in
the jmAttributeTable until the value is known or SHALL return a
zero-length string."
DEFVAL { ''H } -- empty string
::= { jmAttributeEntry 4 }
-- Notifications and Trapping
-- Reserved for the future
jobmonMIBNotifications OBJECT IDENTIFIER ::= { jobmonMIB 2 }
-- Conformance Information
jmMIBConformance OBJECT IDENTIFIER ::= { jobmonMIB 3 }
-- compliance statements
jmMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for agents that implement the
job monitoring MIB."
MODULE -- this module
MANDATORY-GROUPS {
jmGeneralGroup, jmJobIDGroup, jmJobGroup, jmAttributeGroup }
OBJECT jmGeneralJobSetName
SYNTAX JmUTF8StringTC (SIZE(0..8))
DESCRIPTION
"Only 8 octets maximum string length NEED be supported by the
agent."
OBJECT jmJobOwner
SYNTAX JmJobStringTC (SIZE(0..16))
DESCRIPTION
"Only 16 octets maximum string length NEED be supported by the
agent."
-- There are no CONDITIONALLY MANDATORY or OPTIONAL groups.
::= { jmMIBConformance 1 }
jmMIBGroups OBJECT IDENTIFIER ::= { jmMIBConformance 2 }
jmGeneralGroup OBJECT-GROUP
OBJECTS {
jmGeneralNumberOfActiveJobs, jmGeneralOldestActiveJobIndex,
jmGeneralNewestActiveJobIndex, jmGeneralJobPersistence,
jmGeneralAttributePersistence, jmGeneralJobSetName}
STATUS current
DESCRIPTION
"The general group."
::= { jmMIBGroups 1 }
jmJobIDGroup OBJECT-GROUP
OBJECTS {
jmJobIDJobSetIndex, jmJobIDJobIndex }
STATUS current
DESCRIPTION
"The job ID group."
::= { jmMIBGroups 2 }
jmJobGroup OBJECT-GROUP
OBJECTS {
jmJobState, jmJobStateReasons1, jmNumberOfInterveningJobs,
jmJobKOctetsPerCopyRequested, jmJobKOctetsProcessed,
jmJobImpressionsPerCopyRequested, jmJobImpressionsCompleted,
jmJobOwner }
STATUS current
DESCRIPTION
"The job group."
::= { jmMIBGroups 3 }
jmAttributeGroup OBJECT-GROUP
OBJECTS {
jmAttributeValueAsInteger, jmAttributeValueAsOctets }
STATUS current
DESCRIPTION
"The attribute group."
::= { jmMIBGroups 4 }
END5. Appendix A - Implementing the Job Life Cycle ✨
okay so a job literally has a whole life cycle 💅 it has well-defined states, and client operations are what push it from one state to the next. internal server and device actions can move it between states too, and all of that together is called the job's life cycle 🦋
not every implementation of job submission protocols has all of the states, and that's totally fine 🌸 the job model here is meant to be a superset of most implementations, so it's the agent's job to map the particular implementation's life cycle onto this one. the agent MAY omit any states not implemented. only the processing and completed states are required to be implemented by an agent 🫶 but a conforming management application SHALL be prepared to accept any of the states in the job life cycle specified here, so it can interoperate with any conforming agent 💜
the job states are meant to be user visible 👀 the agent SHALL make these states visible in the MIB, but only for the subset of job states that the implementation has. some implementations MAY need sub-states of these user-visible states, and the jmJobStateReasons1 object and the jobStateReasonsN (N=2..4) attributes can be used to represent those sub-states of the jobs 🧚
job states are usually meant to last a user-visible length of time 🕰️ but some jobs may pass through some states in zero time in some situations and/or in some implementations. no cap, that's just how it goes sometimes ✨
the job model does not specify how accounting and auditing is implemented, except to assume that accounting and auditing logs are separate from the job life cycle and last longer than job entries in the MIB 🍓 jobs in the completed, aborted, or canceled states are not logs, since they're accessible via SNMP protocol operations, and they SHALL be removed from the Job Monitoring MIB tables after a site-settable or implementation-defined period of time 💀 an accounting application MAY copy accounting information incrementally to an accounting log as a job processes, or MAY be copied while the job is in the canceled, aborted, or completed states, depending on implementation. the same is true for auditing logs 🎀
the jmJobState object specifies the standard job states, and the normal job state transitions are shown in the state transition diagram presented in Figure 4 🌈
6. APPENDIX B - Support of Job Submission Protocols 🎀
bestie, there's a companion PWG document, entitled "Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB" [protomap] 📚 it lists the recommended usage of each object and attribute in this MIB with a bunch of job submission protocols, including which job submission ID format should be used for each protocol 🫶
some job submission protocols let the client specify a job submission ID 💖 a second approach is to enhance the document format so the job submission ID gets embedded in the document data, and that approach is independent of the job submission protocol. this appendix lists some examples of both approaches ✨
some PJL implementations wrap a banner page as a PJL job around a job submitted by a client 🧾 if that results in multiple job submission IDs, the agent SHALL create multiple jmJobIDEntry rows in the jmJobIDTable that each point to the same job entry in the job tables. see the specification of the jmJobIDEntry 👑
7. References ✨
okay bestie, this is the reading list 📚 every source the spec leans on is here, so if you're ever like "wait, where does this come from," it's all in this list 🫶
[BCP-11]Bradner S. and R. Hovey, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.[GB2312]GB 2312-1980, "Chinese People's Republic of China (PRC) mixed one byte and two byte coded character set"[hr-mib]Grillo, P. and S. Waldbusser, "Host Resources MIB", RFC 1514, September 1993.[iana]Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.[IANA-charsets]Coded Character Sets registered by IANA and assigned an enum value for use in the CodedCharSet textual convention imported from the Printer MIB. Seeftp://ftp.isi.edu/in-notes/iana/assignments/character-sets[iana-media-types]IANA Registration of MIME media types (MIME content types/subtypes). Seeftp://ftp.isi.edu/in-notes/iana/assignments/[ipp-model]deBry, R., Hastings, T., Herriot, R., Issaacson, S. and P. Powell, "The Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.[ISO-639]ISO 639:1988 (E/F) - Code for Representation of names of languages - The International Organization for Standardization, 1st edition, 1988.[ISO-646]ISO/IEC 646:1991, "Information technology -- ISO 7-bit coded character set for information interchange", JTC1/SC2.[ISO-2022]ISO/IEC 2022:1994 - "Information technology -- Character code structure and extension techniques", JTC1/SC2.[ISO-3166]ISO 3166:1988 (E/F) - Codes for representation of names of countries - The International Organization for Standardization, 3rd edition, 1988-08-15."[ISO-8859-1]ISO/IEC 8859-1:1987, "Information technology -- 8-bit single byte coded graphic character sets - Part 1: Latin alphabet No. 1, JTC1/SC2."[ISO-10646]ISO/IEC 10646-1:1993, "Information technology -- Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, JTC1/SC2.[iso-dpa]ISO/IEC 10175-1:1996 "Information technology -- Text and Office Systems -- Document Printing Application (DPA) -- Part 1: Abstract service definition and procedures. Seeftp://ftp.pwg.org/pub/pwg/dpa/[JIS X0208]JIS X0208-1990, "Japanese two byte coded character set."[mib-II]McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.[print-mib]Smith, R., Wright, F., Hastings, T., Zilles, S. and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995.[print-mib-draft]Turner, R., "Printer MIB", Work in Progress,[protomap]Bergman, R., "Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB", RFC 2708, November 1999.[pwg]The Printer Working Group is a printer industry consortium open to any individuals. For more information, access the PWG web page:http://www.pwg.org[RFC1179]McLaughlin, L., III, "Line Printer Daemon Protocol", RFC 1179, August 1990.[RFC1738]Berners-Lee, T., Masinter, L. and M., McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.[RFC1766]Avelstrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.[RFC2026]Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.[RFC2119]Bradner, S., "Keywords for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2277]Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.[RFC2278]Freed, N. and J. Postel, "IANA CharSet Registration Procedures", BCP 19, RFC 2278, January 1998.[SMIv2-SMI]McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.[SMIv2-TC]McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.[tipsi]IEEE 1284.1, Transport-independent Printer System Interface (TIPSI).[URI-spec]Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI), Generic Syntax", RFC 2396, August 1998.[US-ASCII]Coded Character Set - 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.[UTF-8]Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
8. Notices 🎀
so this part is the legal-ish bit, but it's still important, no cap 💅
The IETF doesn't take a position on whether any intellectual property or other rights that might be claimed to apply to the technology in this document are valid or in scope, or on whether any license under those rights might or might not be available. It also doesn't say it has tried to find any such rights. If you want the IETF's rules about rights in standards-track and standards-related documents, check out BCP-11 [BCP-11]. Copies of claims of rights made available for publication, and any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can be requested from the IETF Secretariat.
The IETF also invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Send that info to the IETF Executive Director 🫶
9. Authors' Addresses 💖
the authors, the people who actually built this, in one place. you can literally reach them 🦋
Ron Bergman
Dataproducts Corp.
1757 Tapo Canyon Road
Simi Valley, CA 93063-3394
Phone: 805-578-4421
Fax: 805-578-4001
EMail: rbergma@dpc.com
Tom Hastings
Xerox Corporation, ESAE-231
737 Hawaii St.
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-5514
EMail: hastings@cp10.es.xerox.com
Scott A. Isaacson
Novell, Inc.
122 E 1700 S
Provo, UT 84606
Phone: 801-861-7366
Fax: 801-861-4025
EMail: scott_isaacson@novell.com
Harry Lewis
IBM Corporation
6300 Diagonal Hwy
Boulder, CO 80301
Phone: (303) 924-5337
EMail: harryl@us.ibm.comSend questions and comments to the Printer Working Group (PWG) using the Job Monitoring Project (JMP) Mailing List: jmp@pwg.org
To learn how to subscribe, send email to: jmp-request@pwg.org. Implementers of this specification are encouraged to join the jmp mailing list ✨ so they can take part in the chats about any clarifications needed, and in the registration proposals for additional attributes and values being reviewed, so everyone can reach consensus 🌈
For further information, check out the PWG web page under "JMP": http://www.pwg.org/
Other Participants:
- Chuck Adams - Tektronix
- Jeff Barnett - IBM
- Keith Carter, IBM Corporation
- Jeff Copeland - QMS
- Andy Davidson - Tektronix
- Roger deBry - IBM
- Mabry Dozier - QMS
- Lee Farrell - Canon
- Steve Gebert - IBM
- Robert Herriot - Sun Microsystems Inc.
- Shige Kanemitsu - Kyocera
- David Kellerman - Northlake Software
- Rick Landau - Digital
- Pete Loya - HP
- Ray Lutz - Cognisys
- Jay Martin - Underscore
- Mike MacKay, Novell, Inc.
- Stan McConnell - Xerox
- Carl-Uno Manros, Xerox, Corp.
- Pat Nogay - IBM
- Bob Pentecost - HP
- Rob Rhoads - Intel
- David Roach - Unisys
- Stuart Rowley - Kyocera
- Hiroyuki Sato - Canon
- Bob Setterbo - Adobe
- Gail Songer, EFI
- Mike Timperman - Lexmark
- Randy Turner - Sharp
- William Wagner - Digital Products
- Jim Walker - Dazel
- Chris Wellens - Interworking Labs
- Rob Whittle - Novell
- Don Wright - Lexmark
- Lloyd Young - Lexmark
- Atsushi Yuki - Kyocera
- Peter Zehler, Xerox, Corp.
the whole squad that helped out 🌈💜
10 INDEX ✨
okay bestie, this is the index, and it's basically a cheat sheet for finding everything fast 🗂️💖 Textual conventions (the named data types) all start with JM and end with TC. Objects start with jm and then the group name. Attributes are the enums, so they start with a lowercase letter and don't get any special prefix. Here's the whole list, sorted, with the page numbers 🧚
colorantConsumed, 40
colorantRequested, 40
deviceNameRequested, 30
documentCopiesCompleted, 35
documentCopiesRequested, 35
documentFormat, 31
documentFormatIndex, 31
documentName, 31
fileName, 31
finishing, 33
fullColorImpressionsCompleted, 37
highlightColorImpressionsCompleted, 37
impressionsCompletedCurrentCopy, 37
impressionsInterpreted, 37
impressionsSentToDevice, 37
impressionsSpooled, 36
jmAttributeInstanceIndex, 99
jmAttributeTypeIndex, 98
JmAttributeTypeTC, 78
jmAttributeValueAsInteger, 99
jmAttributeValueAsOctets, 100
JmBooleanTC, 72
JmFinishingTC, 70
jmGeneralAttributePersistence, 87
jmGeneralJobPersistence, 87
jmGeneralJobSetIndex, 85
jmGeneralJobSetName, 88
jmGeneralNewestActiveJobIndex, 86
jmGeneralNumberOfActiveJobs, 86
jmGeneralOldestActiveJobIndex, 86
JmJobCollationTypeTC, 74
jmJobIDJobIndex, 91
jmJobIDJobSetIndex, 90
jmJobImpressionsCompleted, 96
jmJobImpressionsPerCopyRequested, 95
jmJobIndex, 92
jmJobKOctetsPerCopyRequested, 94
jmJobKOctetsProcessed, 94
jmJobOwner, 96
JmJobServiceTypesTC, 81
JmJobSourcePlatformTypeTC, 69
jmJobState, 92
jmJobStateReasons1, 93
JmJobStateReasons1TC, 83
JmJobStateReasons2TC, 83
JmJobStateReasons3TC, 83
JmJobStateReasons4TC, 84
JmJobStateTC, 75
JmJobStringTC, 68
jmJobSubmissionID, 89
JmJobSubmissionIDTypeTC, 74
JmMediumTypeTC, 72
JmNaturalLanguageTagTC, 68
jmNumberOfInterveningJobs, 93
JmPrinterResolutionTC, 71
JmPrintQualityTC, 71
JmTimeStampTC, 69
JmTonerEconomyTC, 72
JmUTF8StringTC, 68
jobAccountName, 27
jobCodedCharSet, 26
jobCollationType, 36
jobComment, 31
jobCompletionTime, 43
jobCopiesCompleted, 35
jobCopiesRequested, 35
jobHold, 33
jobHoldUntil, 33
jobKOctetsTransferred, 35
jobName, 28
jobNaturalLanguageTag, 27
jobOriginatingHost, 30
jobPriority, 32
jobProcessAfterDateAndTime, 32
jobProcessingCPUTime, 43
jobServiceTypes, 29
jobSourceChannelIndex, 29
jobSourcePlatformType, 29
jobStartedBeingHeldTime, 42
jobStartedProcessingTime, 43
jobStateReasons2, 25
jobStateReasons3, 25
jobStateReasons4, 25
jobSubmissionTime, 42
jobSubmissionToServerTime, 42
jobURI, 27
mediumConsumed, 40
mediumRequested, 39
mediumSizeConsumed, 41
mediumTypeConsumed, 41
numberOfDocuments, 30
other, 25
outputBin, 33
pagesCompleted, 38
pagesCompletedCurrentCopy, 38
pagesRequested, 38
physicalDevice, 30
printerResolutionRequested, 34
printerResolutionUsed, 34
printQualityRequested, 34
printQualityUsed, 34
processingMessage, 25
processingMessageNaturalLangTag, 26
queueNameRequested, 30
serverAssignedJobName, 28
sheetCompletedCopyNumber, 36
sheetCompletedDocumentNumber, 36
sheetsCompleted, 39
sheetsCompletedCurrentCopy, 39
sheetsRequested, 39
sides, 33
submittingApplicationName, 29
submittingServerName, 29
tonerDensityRequested, 34
tonerDensityUsed, 34
tonerEcomonyRequested, 34
tonerEcomonyUsed, 3411 Full Copyright Statement 💜
Legal time, but make it cute 🎀 The legal text below stays word for word, because the rules about copying and changing this document are super important and we don't want to accidentally mess them up 🙈
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement 🌸
The RFC Editor function is currently funded by the Internet Society, so a big thank-you to them 🫶✨
📦 where this page comes from
- ietf: rfc2707 1999-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms