RFC 2708
Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB
RFC 2708 ๐ Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB
okay bestie, let's get into it ๐ง this is RFC 2708, written by R. Bergman from Dataproducts Corp. ๐จ๏ธ It's filed as Informational (so it's giving "here's useful info," not an official Internet standard) and it's dated November 1999. The title block doesn't list anything it obsoletes or updates, so it's a standalone doc ๐
Status of This Memo โจ
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice ๐
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract ๐ฆ
This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB.
Table of Contents ๐๏ธ
1.0 INTRODUCTION.................................................2
2.0 LINE PRINTER DAEMON (LPR/LPD) PROTOCOL.......................4
2.1 jmJobSubmissionID Mapped to LPR/LPD..........................4
2.2 jmJobIndex Mapped to LPR/LPD.................................5
2.3 Other MIB Objects Mapped to LPR/LPD..........................5
2.4 The Attribute Group Mapped to LPD............................5
3.0 APPLETALK PROTOCOL...........................................6
3.1 jmJobSubmissionID Mapped to AppleTalk........................6
3.2 Other AppleTalk Mappings.....................................6
4.0 INTERNET PRINTING PROTOCOL (IPP).............................6
4.1 jmJobSubmissionID Mapped to IPP..............................7
4.2 jmJobIndex Mapped to IPP.....................................7
4.3 Other MIB Objects Mapped to IPP..............................8
4.4 The Attribute Group Mapped to IPP............................8
5.0 INTELLIGENT PRINTER DATA STREAM (IPDS)......................10
5.1 jmJobSubmissionId Mapped to IPDS............................10
5.2 The Attribute Group Mapped to IPDS..........................11
6.0 DOCUMENT PRINTING APPLICATION (DPA).........................11
6.1 jmJobSubmissionID Mapped to DPA.............................11
6.2 jmJobIndex Mapped to DPA....................................12
6.3 Other MIB Objects Mapped to DPA.............................12
6.4 The Attribute Group Mapped to DPA...........................13
7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS).....................14
7.1 jmJobSubmissionID Mapped to NDPS............................14
7.2 jmJobIndex Mapped to NDPS...................................14
7.3 Other MIB Objects Mapped to NDPS............................15
7.4 The Attribute Group Mapped to NDPS..........................15
8.0 PRINTER JOB LANGUAGE (PJL)..................................17
8.1 jmJobSubmissionID Mapped to PJL.............................17
8.2 jmJobIndex Mapped to PJL....................................18
8.3 Other MIB Objects Mapped to PJL.............................18
8.4 The Attribute Group Mapped to PJL...........................18
9.0 POSTSCRIPT..................................................18
9.1 jmJobSubmissionID Mapped to PostScript......................19
9.2 Other MIB Objects and Attributes Mapped to PostScript.......19
10.0 NETWARE PSERVER............................................19
10.1 jmJobSubmissionID Mapped to PServer........................19
10.2 jmJobIndex Mapped to PServer...............................19
10.3 Other MIB Objects Mapped to PJL............................20
10.4 The Attribute Group Mapped to PServer......................20
11.0 NETWARE NPRINTER or RPRINTER...............................20
12.0 SERVER MESSAGE BLOCK (SMB) PROTOCOL........................21
12.1 jmJobSubmissionID Mapped to SMB............................21
12.2 jmJobIndex Mapped to SMB...................................21
12.3 Other MIB objects Mapped to SMB............................21
13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI)....22
13.1 jmJobSubmissionID Mapped to TIP/SI.........................22
13.2 jmJobIndex Mapped to TIP/SI................................22
13.3 Other MIB Objects Mapped to TIP/SI.........................22
13.4 The Attribute Group Mapped to TIP/SI.......................22
14.0 SECURITY CONSIDERATIONS....................................23
15.0 REFERENCES.................................................23
16.0 AUTHORS' ADDRESSES.........................................24
17.0 FULL COPYRIGHT STATEMENT...................................26
1.0 INTRODUCTION ๐ธ
okay so the Job Monitoring MIB [JobMIB] is meant to be built into a device or server that supports any job submission protocol ๐จ๏ธ but the info you get and how it's presented is wildly different from protocol to protocol. so you need a common way to map job submission info into the Job MIB, or Job MIB agents and monitoring apps won't be able to talk to each other. this doc gives recommended mappings for most of the popular protocols so everything stays compatible ๐ซถ
all the mappings only go one way, from the job submission protocol into the MIB. it's assumed that if the printer supports the job submission protocol, the reverse info flow is already defined and doesn't need the MIB to do anything. this doc doesn't spell that out because it's supposed to be obvious ๐
this doc talks about system configurations defined in the Job Monitoring MIB [JobMIB]. if you already know them, here's a quick recap. read the Job MIB doc for the full details โจ
- Configuration 1: a simple peer-to-peer system with only a client and a printer. The Job MIB agent lives in the printer. ๐จ๏ธ
- Configuration 2: a client, a server, and a printer. The Jib MIB agent lives in the server. ๐ฅ๏ธ
- Configuration 3: same as configuration 2 (client, server, printer), except the Job MIB agent is built into the printer instead. ๐ง
the most important object to map is jmJobSubmissionID ๐ because it's how the user or client figures out the jmJobIndex for a job they submitted. that's why jmJobSubmissionID gets specified for every job submission protocol in this doc. the other objects only get mapped if the protocol gives the printer equivalent info.
so this doc puts a lot of emphasis on jmJobSubmissionID for getting jmJobIndex ๐ but the preferred way is a bi-directional job submission protocol that hands the client the equivalent of jmJobIndex directly, like IPP. when a bi-directional protocol returns jmJobIndex, jmJobSubmissionID has no value to the client. if jmJobIndex can't be returned, a client defined jmJobSubmissionID is preferred over one the agent derives. why? the client defined version lets you grab jmJobIndex with a single SNMP Get operation, because jmJobSubmissionID is the index into the jmJobIDTable. an agent derived value would mean searching through multiple entries in the jmJobIDTable ๐
most of the protocols in this doc are for network job submission. but the Job Monitoring MIB also monitors print jobs that come in through non-network ports, like parallel and serial ports ๐ some of the protocols used with those non-networked ports are PJL, PostScript, and TIP/SI. the Job MIB can also handle print jobs that the printer generates internally, like self test pages. for those, no mapping is needed because all the job submission protocols get bypassed ๐
2.0 LINE PRINTER DAEMON (LPR/LPD) PROTOCOL ๐จ๏ธ
the LPR/LPD printing protocol [LPD] is used on BSD UNIX systems in the client-server-printer setup ๐ง using the Job MIB with LPR/LPD will most likely look like Configuration 3, where the monitor app or the server uses SNMP to get job info from the printer. the client talks to the UNIX server with the existing LPD protocol to get job info.
LPR/LPD is also used in Windows for peer-to-peer printing, as in configuration 1 ๐ช in that case the client and/or the monitor app use SNMP to get the job info.
the big headache with LPR/LPD is the huge pile of vendor unique extensions people use with it, which causes compatibility drama between implementations ๐ญ to avoid that, this LPR/LPD mapping is restricted to the protocol as defined by RFC 1179 ๐
LPR/LPD sends the print job data and the control info in separate files: the Data File and the Control File. most of the job info lives in the Control File ๐ in lots of LPD implementations, the Control File gets sent after the Data File. so a lot of the job info might not be available until the data transmission is done ๐
2.1 jmJobSubmissionID Mapped to LPR/LPD ๐
the LPR/LPD Receive Data File command has a parameter that names the data file. that name field looks like this:
dfaXXX<host-name> or daXXXX<host-name>
the XXX or XXXX part is the numeric job number assigned by whatever network entity submitted the job to the printer โจ the recommended mapping of this name field to jmJobSubmissionID goes like this:
octet 1:'9'octets 2-40:holds the<host-name>portion of the name field. if<host-name>is less than 40 octets, the left-most character in the string shall appear in octet position 2. any unused part of this field shall be filled with spaces. otherwise, only the last 39 bytes shall be included.octets 41-48:'00000XXX'or'0000XXXX', where XXX or XXXX is the decimal (ASCII coded) representation of the LPR/LPD job number ๐ข
2.2 jmJobIndex Mapped to LPR/LPD ๐ฆ
the job index (jmJobIndex) is assigned by the SNMP job monitoring agent, and it's independent of the XXX (or XXXX) index the LPR/LPD client assigns. this lets the SNMP agent keep track of jobs coming in from multiple sources ๐
2.3 Other MIB Objects Mapped to LPR/LPD ๐
MIB Object | LPR/LPD Parameter
------------------------------+----------------------------------------
jmJobKOctetsPerCopyRequested | Number of bytes as defined in the Data
| File
jmJobOwner | Control file command code = P (User Id)
2.4 The Attribute Group Mapped to LPD ๐ง
other attributes that apply but aren't defined in this section, like ones that map to a vendor unique extension, may also be included โจ
MIB attribute | LPR/LPD information | Data type
----------------------+---------------------------------+--------------
jobName | Job Name (notes 1, 2) | Octet String
queueNameRequested | Queue name from the Data File | Octet String
fileName | Source File Name (notes 1, 3) | Octet String
Notes:
- The information is optional in the Control File. ๐ The attribute should be included if it's present in the Control File.
- Control file command code = J. ๐ซถ If this optional field is left out of the control file, then the agent returns the file name (command code = N), if there is one.
- Control file command code = N. ๐
3.0 AppleTalk Protocol ๐
okay so AppleTalk started out as a peer-to-peer network protocol (that's configuration 1 ๐) and it was built for Apple Macintosh computers. nowadays print spoolers also work with Macintosh networks that follow configurations 2/3, and printing over AppleTalk is supported from both Windows NT servers and Novell servers in those same configurations โจ
ngl, AppleTalk doesn't give us a ton of info for the Job Monitoring MIB ๐ญ The Macintosh print drivers can tell you the user and document name, but they bury all of that inside the PDL (usually PostScript). So the preferred jmJobSubmissionID gets built from the PostScript file itself, as described in section 9.0 ๐ง
3.1 jmJobSubmissionID Mapped to AppleTalk
an alternative jmJobSubmissionID may be built from the Connection Identifier in the AppleTalk Printer Access Protocol (PAP) header ๐ฆ BUT the Connection Id isn't really easy to get in any of the AppleTalk implementations that exist, so this approach may not be super useful ๐
here's the layout, copied exactly:
octet 1: 'A'
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 decimal (ASCII coded)
representation of the Connection Id.
so basically: octet 1 is the letter 'A' ๐ธ Octets 2-40 hold the printer name, starting at octet 2, and since names top out at 31 characters, any leftover space in that field gets filled with spaces. Octets 41-48 hold the Connection Id as decimal ASCII digits ๐
3.2 Other AppleTalk Mappings
no other Job MIB objects or parameters can be pulled from the information in the AppleTalk headers ๐ญ that's it, that's the tea โ
4.0 Internet Printing Protocol (IPP) ๐จ๏ธ
the Internet Printing Protocol [IPP] works with all three possible configurations ๐ For configuration 2, the mapping in this section gets done on an agent inside the server. For everything else, the mapping happens on an agent inside the printer ๐
4.1 jmJobSubmissionID Mapped to IPP
IPP has a super rich set of parameters, so there are a bunch of ways to make the jmJobSubmissionID ๐คฏ To avoid interoperability problems, the preferred move is to use the IPP job-uri attribute like this:
octet 1: '4'
octets 2-40: Contains the IPP job-uri job description attribute
generated by the printer. (The job-uri is returned to
the client by IPP.) If the job-uri 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: Contains the decimal (ASCII coded) representation of
the job-id job description attribute. Leading zeros
shall be inserted to fill the entire 8 octet field.
so octet 1 is '4' ๐ Octets 2-40 hold the job-uri the printer generated (the client gets this back from IPP). If the job-uri is shorter than 40 octets, the leftmost character goes in octet 2 and the unused bit gets spaces. If it's longer, only the last 39 bytes get included ๐ฆ Octets 41-48 hold the job-id as decimal ASCII, padded with leading zeros to fill all 8 octets ๐ธ
NOTE - Since IPP returns the "job-identifier" attribute with the jmJobIndex value for a job when the job is submitted, the use of the jmJobSubmissionID table should not be needed by a management application. See Section 1.0. ๐
4.2 jmJobIndex Mapped to IPP
the job index (jmJobIndex) that the SNMP job monitoring agent assigns gets handed back to the client by IPP as the job-id job description attribute ๐ง (Since IPP doesn't require job-ids to be generated consecutively, the agent might get jobs from lots of different clients, and it can assign jmJobIndex in ascending order no matter which client submitted the job ๐ ) The IPP job-id must be kept in the range of 1 to 99,999,999 (decimal) so the value can be represented properly in jmJobSubmissionID ๐ฅ
4.3 Other MIB Objects Mapped to IPP
here's the mapping table, exactly as it's written:
MIB Object | IPP Job attribute
---------------------------------+-----------------------------------
jmJobState | job-state
jmJobStateReasons1 | job-state-reasons (note 1)
jmNumberOfInterveningJobs | number-of-intervening-jobs
jmJobKOctetsPerCopyRequested | job-k-octets
jmJobKOctetsProcessed | job-k-octets-processed
jmJobImpressionsPerCopyRequested | job-impressions
jmJobImpressionsCompleted | job-impressions-completed
jmJobOwner | job-originating-user-name
Notes:
- jmJobStateReasons1 is a bit map that can describe up to 31 job state reasons ๐ Also, the IPP "job-state-reasons" attribute is multi-valued, and every value is a keyword. The IPP condition may change multiple bits in this object. The IPP "job-state-reasons" attribute may also change one or more of the jobStateReasonsN attributes (see section 4.4) โจ
4.4 The Attribute Group Mapped to IPP
the following mappings are required if the listed IPP job template attribute is provided ๐ซถ Here's the full table:
MIB attribute | IPP job attribute | Data type
---------------------------+------------------------------+-------------
jobStateReasonsN(N=2, 3, 4)| job-state-reasons (note 3) | Integer
jobCodedCharSet | attributes-charset (note 1) | Octet String
jobNaturalLanguageTag | attributes-natural-language | Octet String
jobURI | job-uri | Octet String
jobName | job-name | Octet String
physicalDevice | output-device-assigned | Octet String
numberOfDocuments | number-of-documents | Integer
jobPriority | job-priority | Integer
jobHoldUntil | job-hold-until | Octet String
sides | sides (note 2) | Integer
finishing | finishings | Integer
printQualityRequested | print-quality | Integer
printerResolutionRequested | printer-resolution | Integer
jobCopiesRequested | copies (note 4) | Integer
documentCopiesRequested | copies (note 4) | Integer
jobCollationType | multiple-document-handling | Integer
sheetsRequested | job-media-sheets | Integer
sheetsCompleted | job-media-sheets-completed | Integer
mediumRequested | media | Octet String
jobSubmissionTime | time-at-submission | Integer
jobStartedProcessingTime | time-at-processing | Integer
jobCompletionTime | time-at-completed | Integer
Notes:
- jobCodedCharSet is an enum from the IANA registry, and it's also used in the Printer MIB ๐ The IPP attributes-charset is the name (MIME preferred name) of the character set.
- The Job MIB sides attribute uses the integer values "1" and "2". The IPP sides attribute uses three keywords ๐ฅ
- jobStateReasonsN is three attributes (N=2, 3, 4). Also the IPP "job-state-reasons" attribute is multi-valued, with each value being a keyword. The IPP condition may change multiple bits in one or more of these Job MIB attributes. See also jmJobStateReasons1 in section 4.3 ๐ง
- The IPP "copies" attribute maps to the Job MIB like this:
- (1) jobCopiesRequested when the job has only one document OR IPP "multiple-document-handling" is 'single-valued'
- (2) documentCopiesRequested, in which case the MIB value is the total number of document copies that the job will produce as a whole ๐
5.0 Intelligent Printer Data Stream (IPDS) ๐ฆ
the IPDS datastream creates a super close relationship between the print supervisor (Print Services Facility - PSF) and the printer ๐ค There are PSF applications for UNIX, Windows, OS/2, OS/400, and host operating systems like VM, MVS, and VSE. Together, PSF and IPDS make a complete, mature, and robust job management framework ๐ It covers font and resource management, page progress tracking, job cancellation, complete error recovery, and end-user notification. Because PSF and the printer talk to each other using locally assigned IDs, there's only a limited amount of clear text info given during submission for the Job MIB ๐
5.1 jmJobSubmissionId Mapped to IPDS
for IPDS on the MVS or VSE platform:
octet 1: 'E'
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: Contains a decimal (ASCII coded) representation of the
jmJobIndex assigned by the agent. Leading zeros shall
be inserted to fill the entire 8 octet field.
for IPDS on the VM platform:
octet 1: 'F'
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: Contains a decimal (ASCII coded) representation of the
jmJobIndex assigned by the agent. Leading zeros shall
be inserted to fill the entire 8 octet field.
for IPDS on the OS/400 platform:
octet 1: 'G'
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: Contains a decimal (ASCII coded) representation of the
jmJobIndex assigned by the agent. Leading zeros shall
be inserted to fill the entire 8 octet field.
so each platform gets its own letter (E, F, or G) and its own slice of the XOH Define Group Boundary Group ID triplet ๐ Octets 41-48 always carry the jmJobIndex in decimal ASCII, zero-padded ๐ธ
5.2 The Attribute Group Mapped to IPDS
for MVS/VSE:
MIB attribute | IPDS XOH DGB Group ID | Data type
----------------------------------+-----------------------+-------------
jobSourcePlatformType sptMVS(7) | Byte 2 = x'01' | Integer
jobName | Bytes 4-11 | Octet String
for VM:
MIB attribute | IPDS XOH DGB Group ID | Data type
----------------------------------+-----------------------+-------------
jobSourcePlatformType sptVM(8) | Byte 2 = x'02' | Integer
fileName | Bytes 4-11 | Octet String
for OS/400:
MIB attribute | IPDS XOH DGB Group ID | Data type
----------------------------------+-----------------------+-------------
jobSourcePlatformType sptOS400(9) | byte 2 = x'03' | Integer
fileName | Bytes 23-32 | Octet String
jobName | Bytes 37-46 | Octet String
6.0 Document Printing Application (DPA) ๐
the ISO 10175 Document Printing Application (DPA) [DPA] works with all three possible configurations ๐ For configuration 2, the mapping in this section gets done on a server. For everything else, the mapping happens on an agent inside the printer ๐
6.1 jmJobSubmissionID Mapped to DPA โจ
okay so DPA has a lot of parameters, which means there are several different ways to build a jmJobSubmissionID object ๐ซ to keep everyone interoperable, the preferred method is to use the DPA job-owner attribute, laid out like this:
octet 1: '0'
octets 2-40: Contains the DPA job-owner attribute supplied by the
submitter. If the job-owner 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: Contains an 8-digit sequential decimal number.
so octet 1 is just '0', octets 2 to 40 hold the job-owner (left-most character goes in octet 2, leftover space gets filled with spaces, and anything longer than 40 octets gets chopped down to its last 39 bytes ๐
), and octets 41 to 48 hold an 8-digit sequential decimal number. ngl the chopping rule is very specific and very iconic ๐ญ
6.2 jmJobIndex Mapped to DPA ๐ฆ
okay so the SNMP job monitoring agent assigns the jmJobIndex, and DPA hands it back to the client as a decimal digit string in the DPA job-identifier attribute. here's the fun part: DPA doesn't need job-identifiers to be generated in a row, so the agent can get jobs from a bunch of different clients and still count up in ascending order no matter who submitted what ๐ง that's giving independence!!
the DPA job-identifier must be restricted to the range of 1 to 99,999,999 (decimal) so it can be properly represented in jmJobSubmissionID. no going over that, bestie ๐
NOTE - Since DPA returns the "job-identifier" attribute with the jmJobIndex value for a job when the job is submitted, the use of the jmJobSubmissionID table should not be needed by a management application. See Section 1.0.
^ this note is lowkey the main point: DPA already gives the management app the jmJobIndex when the job goes in, so it usually doesn't need that jmJobSubmissionID table at all. see Section 1.0 for more ๐ธ
6.3 Other MIB Objects Mapped to DPA ๐
here's the big mapping table, copied exactly so nothing gets lost in translation:
MIB Object | DPA Job attribute
---------------------------------+------------------------------------
jmJobState | job-state
jmJobStateReasons1 | job-state-reasons (note 2)
jmNumberOfInterveningJobs | intervening-jobs
jmJobKOctetsPerCopyRequested | total-job-octets (notes 1, 3)
jmJobKOctetsProcessed | job-octets-completed (note 1)
jmJobImpressionsPerCopyRequested | job-impression-count (note 3)
jmJobImpressionsCompleted | impressions-completed
jmJobOwner | job-owner
and the notes, which are the juicy bits ๐ค
jmJobKOctetsPerCopyRequestedandjmJobKOctetsProcessedare in K octets, while DPAjob-total-octetsandjob-octets-completedare in octets and are 63-bits of significance. so the units are totally different, periodt ๐jmJobStateReasons1is a bit map that can describe up to 31 job state reasons. meanwhile, the DPAjob-state-reasonsattribute is multi-valued, and each value is an object identifier (OID). the DPA condition may change multiple bits in this object, and it may also change one or more of thejobStateReasonsNattributes (see section 4.4) ๐ซถ- DPA octets include the multiplication factor from job and document copies, but the MIB values don't ๐
6.4 The Attribute Group Mapped to DPA ๐
the following mappings are required if the listed DPA job attribute is provided. the table is copied exactly, so take a look:
MIB attribute | DPA job attribute |IPP Data type
---------------------------+------------------------------+-------------
jobStateReasonsN(N=2, 3, 4)| job-state-reasons (note 2) | Integer
jobCodedCharSet | (note 1) | Octet String
jobAccountName | accounting-information | Octet String
jobName | job-name | Octet String
deviceNameRequested | printer-name-requested | Octet String
physicalDevice | printers-assigned | Octet String
numberOfDocuments | number-of-documents | Integer
fileName | file-name | Octet String
documentName | document-name | Octet String
jobComment | job-comment | Octet String
documentFormat | document-format | Octet String
jobPriority | job-priority | Integer
jobProcessAfterDateAndTime | job-print-after | Octet String
outputBin | results-profile.output-bin | Octet String
sides | sides (note 3) | Integer
finishing | job-finishing, finishing | Integer
printQualityRequested | print-quality | Integer
printerResolutionRequested | default-printer-resolution | Integer
| (note 4) |
jobCopiesRequested | results-profile.job-copies | Integer
jobCopiesCompleted | job-copies-completed | Integer
documentCopiesRequested | copy-count (note 5) | Integer
documentCopiesCompleted | copies-completed (note 6) | Integer
sheetsRequested | job-media-sheet-count | Integer
sheetsCompleted | job-media-sheets-completed | Integer
pagesRequested | job-page-count | Integer
pagesCompleted | pages-completed | Integer
mediumRequested | page-media-select, | Octet String
| default-medium |
jobSubmissionTime | submission-time (note 7) | Octet String
jobStartedProcessingTime | started-printing-time (note 7) Octet String
jobCompletionTime | completion-time (note 7) | Octet String
and the notes for this table:
- every DPA attribute is tagged to show which coded character set goes with it ๐
jobStateReasonsNis three attributes (N=2, 3, 4). the DPA condition may change one or more bits in one or more of these Job MIB items. also, the DPAjob-state-reasonsis multi-valued, with each value being an OBJECT IDENTIFIER (OID) ๐- the Job MIB
sidesattribute is an integer '1' or '2', while the DPAsidesattribute has one of six OID values, one of which includes plex ๐ฅ printerResolutionRequestedhas x and y resolution and is meant to override the resolution instruction in the document (if there is one). the DPAdefault-printer-resolutionis the same in x and y and only takes effect if the document doesn't have a resolution instruction โจ- the DPA
copy-countattribute is per-document, so the MIB value is the sum of the documents'copy-countvalues times the job'sresults-profile.job-copiesvalue ๐งฎ - the DPA
copies-completedattribute is also per-document, so the MIB value is the sum of the documents'copies-completedvalues times the job'sresults-profile.job-copiesvalue ๐งฎ - the DPA GeneratlizedTime data type is defined by ISO 8824 (ISO-8824), while the MIB DateAndTime is defined by SNMPv2-TC (SNMPv2-TC) ๐ฐ๏ธ
7.0 NOVELL DISTRIBUTED PRINT SERVICE (NDPS) ๐ธ
Novell Distributed Print Services is a DPA based job submission protocol that conforms to configuration 3. it's giving DPA family vibes, and the NDPS crew totally knows it ๐
7.1 jmJobSubmissionID Mapped to NDPS ๐
NDPS can generate a properly formatted jmJobSubmissionID for use in the Job MIB, through the attribute ndps-att-job-identifier. โจ
7.2 jmJobIndex Mapped to NDPS ๐ฆ
NDPS defines the attribute ndps-att-job-identifier-on-printer, which can be used to return the value of jmJobIndex to the NDPS client. see Section 1.0 for the bigger picture ๐ง
7.3 Other MIB Objects Mapped to NDPS ๐
the mapping table, copied exactly:
MIB Object | NDPS Parameter
---------------------------------+--------------------------------------
jmJobState | ndps-att-current-job-state (note 1)
jmJobStateReasons1 | ndps-att-job-state-reasons (note 2)
jmNumberOfInterveningJobs | ndps-att-intervening-jobs
jmJobKOctetsPerCopyRequested | ndps-att-total-job-octets (notes 3,4)
jmJobKOctetsProcessed | ndps-att-octets-completed (note 3)
jmJobImpressionsPerCopyRequested | ndps-att-job-impressions-count
jmJobImpressionsCompleted | ndps-att-impressions-completed
jmJobOwner | ndps-att-job-owner (note 5)
and the notes:
- some of the NDPS job states must be represented by both a
jmJobStateand ajmJobStateReasons1object, or by ajobStateReasonsNattribute (N=2, 3, 4). ๐ซ - the NDPS job state reasons may be mapped to either the object
jmJobStateReasons1or the attributejobStateReasonsN(N=2, 3, 4). ๐ jmJobKOctetsPerCopyRequestedandjmJobKOctetsProcessedare in K octets, while the NDPSndps-att-job-total-octetsandndps-att-job-octets-completedare in octets and are 63-bits of significance. ๐งฎ- NDPS octets include the multiplication factor from job and document copies, but the MIB values don't. ๐
- the Job MIB object must be multiplied by the attribute
jobCopiesRequestedto get the NDPS attribute value, if multiple copies were requested. ๐
7.4 The Attribute Group Mapped to NDPS ๐ซถ
the following mappings are required if the listed PJL attribute or command option is provided. here's the start of the table (copied exactly):
MIB attribute | NDPS parameter | Data type
8.0. PRINTER JOB LANGUAGE (PJL) ๐จ
PJL [PJL] was built by Hewlett-Packard to pass job control info to the printer and status info to apps, no matter which PDL is in use. It's giving well-organized ๐๐
8.1. jmJobSubmissionID Mapped to PJL
PJL has a SUBMISSIONID option for the JOB command that gives you a properly formatted jmJobSubmissionID for the Job MIB ๐ The PJL JOB command goes at the start of a print job, and its options only apply to that one job. The syntax looks like this:
@PJL JOB SUBMISSIONID = "id string"
Driver software that supports this PJL command option has to put the "id string" in one of the client version formats defined in the Job MIB for jmJobSubmissionID.
Drivers that can't create the SUBMISSIONID option are a different story. For those, it is RECOMMENDED that the agent builds jmJobSubmissionID format 0 using the PJL attribute DocOwner or DocOwnerId ๐ซถ
Here's how format 0 is laid out:
- Octet 1 is
'0'. - Octets 2-40 hold the string tied to DocOwner or DocOwnerId. If that string is under 40 octets, its left-most character SHALL sit in octet position 2. If it's longer, only the last 39 bytes SHALL be included. Any unused part of this field SHALL be filled with spaces. And if DocOwner or DocOwnerId can't be grabbed at all, this field SHALL be blank ๐ญ
- Octets 41-48 hold the value of jmJobIndex for the job. Leading zeros SHALL be inserted so the whole 8 octet field is filled ๐ฅ
8.2. jmJobIndex Mapped to PJL
PJL doesn't give us any value that can be mapped to jmJobIndex ๐
8.3. Other MIB Objects Mapped to PJL
MIB Object | PJL Job attribute
----------------------+------------------------------------
jobOwner | DocOwner or DocOwnerId attribute
8.4. The Attribute Group Mapped to PJL
The following mappings are REQUIRED if the listed PJL attribute or command option is provided. โจ
MIB attribute | PJL attribute or command option | Data type
----------------------+----------------------------------+--------------
serverAssignedJobName | DocName attribute or the command | Octet String
| @PJL JOB Name = "string" | Octet String
submittingServerName | SrcServerName attribute | Octet String
jobOriginatingHost | SrcPort attribute | Octet String
queueNameRequested | SrcQ attribute | Octet String
fileName | JobFName attribute | Octet String
jobComment | JobDesc attribute | Octet String
jobSubmissionTime | TimeSubmit attribute | Octet String
9.0. POSTSCRIPT ๐
The PostScript PDL lets you add comment fields that drivers can use to stash job info ๐ There are no restrictions or requirements on what goes in there. What information MAY be included is totally up to you, but a lot of drivers put in the job owner and/or document name ๐ธ
9.1. jmJobSubmissionID Mapped to PostScript
Using a standard format job submission id comment string means printers and drivers from different vendors can actually talk to each other ๐ฆ The following comment string format is RECOMMENDED for PostScript level 1 and level 2 data streams:
%%JMPJobSubmissionId:(id-string)
where "id string" can be any jmJobSubmissionID format reserved for clients.
9.2. Other MIB Objects and Attributes Mapped to PostScript
No other mappings from PostScript comment strings are RECOMMENDED. That said, lots of Job MIB objects and attributes can be defined with vendor unique comment strings ๐ง
10.0. NETWARE PSERVER ๐
The NetWare PServer job submission protocol runs in a client-server-printer system, on the server-to-printer link, as defined in configuration 3 ๐ฅ
10.1. jmJobSubmissionID Mapped to PServer
- Octet 1 is
'B'. - Octets 2-40 hold the Directory Path Name of the agent, as recorded by the Novell File Server in the queue directory. If the string is under 40 octets, its left-most character SHALL sit in octet position 2. If it's longer, only the last 39 bytes SHALL be included. Any unused part of this field SHALL be filled with spaces.
- Octets 41-48 hold
'000XXXXX', which is the decimal (ASCII coded) form of the Job Number, as set by the NetWare File Server Queue Management Services ๐
10.2. jmJobIndex Mapped to PServer
The job index (jmJobIndex) is assigned by the SNMP job monitoring agent, and it's totally separate from the Job Number that NetWare File Server Queue Management Services hands out. That separation lets the SNMP agent keep track of jobs coming in from multiple sources ๐
10.3. Other MIB Objects Mapped to PJL
MIB Object | PServer Job attribute
----------------------+--------------------------------------------
jobOwner | Client Id Number
10.4. The Attribute Group Mapped to PServer
The following mappings are REQUIRED if the listed PServer parameter is provided in the Novell File Server queue directory. ๐
MIB attribute | PServer parameter | Data type
---------------------------+-----------------------------+--------------
serverAssignedJobName | Job File Name | Octet String
queueNameRequested | Queue Id | Integer
physicalDevice | Server Id Number | Integer
jobComment | Job Description | Octet String
jobPriority | (note 1) | Integer
jobProcessAfterDateAndTime | Target Execution Time | Octet String
jobCopiesRequested | Number of Copies | Integer
mediumRequested | Form Name | Octet String
jobSubmissionToServerTime | Job Entry Time | Octet String
Notes:
- The job priority is set by the priority of the queue that holds the job. Each queue can get its own unique priority, and the job just inherits it from the queue ๐
11.0. NETWARE NPRINTER or RPRINTER ๐จ
The NetWare NPrinter/RPrinter protocol was designed to shoot print data from a Novell File Server to a printer plugged straight into a local port (parallel or serial) on a PC. It's super lightweight, which is iconic, but it also means it doesn't carry any of the info the Job Monitoring MIB needs. So a meaningful jmJobSubmissionID just can't be generated ๐
It is RECOMMENDED that you add another job submission layer on top of NPrinter/RPrinter to supply the info you need, such as PJL or some other vendor private protocol. After that, the mapping SHOULD be done according to the recommendations of that higher layer submission protocol ๐ซถ
12.0. SERVER MESSAGE BLOCK (SMB) PROTOCOL ๐ฆ
The Server Message Block protocol is used by several PC Network operating systems, like Microsoft Windows for Workgroups, IBM LAN Server, and Artisoft Lantastic โจ SMB systems that support the Job Monitoring MIB will conform to either configuration 1 or configuration 3.
12.1 jmJobSubmissionID Mapped to SMB โจ
Okay so the first byte is a marker, and it's always the letter C ๐
octet 1: 'C'
Octets 2-40 hold a decimal, ASCII-coded version of the 16 bit SMB Tree Id field. That ID is what uniquely identifies the connection that submitted the job to the printer ๐ The most significant digit goes in octet position 2, and any unused space in this field gets filled with spaces. The SMB Tree Id tops out at 65,535.
octets 2-40: (SMB Tree Id, decimal ASCII)
Octets 41-48 hold a decimal, ASCII-coded File Handle. That's the handle the printer agent sends back to the client when it answers a Create Print File command ๐ Leading zeros fill the whole 8 octet field, so nothing gets awkward.
octets 41-48: (File Handle, decimal ASCII, zero-padded)
12.2 jmJobIndex Mapped to SMB ๐ฆ
It's strongly recommended that the File Handle from the printer agent be identical to jmJobIndex. If they match, the client app doesn't have to go searching on jmJobSubmissionID, which is lowkey so convenient ๐ SMB gives this value a 16 bit field, so the maximum jmJobIndex is 65,535.
12.3 Other MIB objects Mapped to SMB ๐
MIB Object | SMB Parameter
----------------+------------------------------------------------
jmJobOwner | SMB User Id field (note 1)
Notes:
- A decimal (ASCII coded) representation of the SMB User Id numeric shall be presented as jmJobOwner.
13.0 TRANSPORT INDEPENDENT PRINTER/SYSTEM INTERFACE (TIP/SI) ๐ง
Okay this one's a glow-up story. The TIP/SI protocol is currently specified as part of the IEEE 1284 parallel port standards [TIP/SI], but it was originally built as a network protocol ๐ So it's giving flexibility. TIP/SI has the potential to get integrated into any network or non-network configuration, periodt ๐
13.1 jmJobSubmissionID Mapped to TIP/SI ๐
Octet 1 is the letter D ๐
octet 1: 'D'
Octets 2-40 hold the Job Name from the Job Control-Start Job (JC-SJ) command. If the Job Name is shorter than 40 octets, the left-most character goes in octet position 2 and any leftover space gets filled with spaces. If it's longer, only the last 39 bytes get included, so the tail end is what makes the cut โ๏ธ
octets 2-40: (Job Name from JC-SJ)
Octets 41-48 hold a decimal, ASCII-coded jmJobIndex that the agent assigned. Leading zeros fill the entire 8 octet field ๐ธ
octets 41-48: (jmJobIndex, decimal ASCII, zero-padded)
13.2 jmJobIndex Mapped to TIP/SI ๐ซถ
jmJobIndex gets sent back to the client as the Printer Assigned Job Id in a Job Control-Start Job (JC-SJ) response packet. TIP/SI gives this value a 16 bit field, so the maximum jmJobIndex is 65,535 โจ
13.3 Other MIB Objects Mapped to TIP/SI ๐
MIB Object | TIP/SI Parameter
-----------------------+---------------------------------------------
jmJobOwner | User string
13.4 The Attribute Group Mapped to TIP/SI ๐ฆ
MIB attribute | TIP/SI information | Data type
----------------------+---------------------------------+-------------
jobName | Job Name string | Octet String
jobComment | Additional Information string | Octet String
14.0 Security Considerations ๐
This part is serious bestie, so read it all ๐จ
This document gives mapping recommendations for job submission protocols that get used with the Job Monitoring MIB. The mapping procedures defined here do not enhance or compromise any security provisions that already exist in the job submission protocols covered in this document.
The security considerations for the Job Monitoring MIB [JobMIB] are also unaffected by any of the recommendations in this document.
The security provisions in the job submission protocols are documented in the specs that define those protocols. How much security you get really varies, from very good for something like the Internet Printing Protocol [IPP], to non-existent for something like the Line Printer Daemon Protocol [LPD] ๐ฌ
The defined mapping operation happens as a secondary step, after the user has already been authenticated, and no authorization credentials get stored apart from the user name. So no security breaches are anticipated ๐ Also, the Job MIB doesn't give any back-door way to reach other security parameters. Still, implementers must always consider how the defined mapping procedures affect the security model wanted from the protocol. Don't skip this part, it's important ๐จ
15.0 REFERENCES ๐
- [DPA] ISO/IEC 10175-1:1996(E), "Information technology - Text and office systems - Document Printing Application (DPA) - Part 1: Abstract service definition and procedures", JTC1/SC18.
- [IPP] 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-8824] ISO/IEC 8824:1990, "Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation (ASN.1)".
- [JobMIB] Bergman, R., Hastings, T., Isaacson, S. and H. Lewis, "The Job Monitoring MIB - V1.0", RFC 2707, November 1999.
- [LPD] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, August 1990.
- [PJL] Printer Job Language Technical Reference Manual, Hewlett-Packard part number 5021-0328.
- [PrtMIB] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995.
- [SNMPv2-TC] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [TIP/SI] IEEE Standard 1284.1, Transport Independent Printer/System Interface.
16.0 Authors' Addresses ๐
This document was created with significant contributions from the following individuals.
Ron Bergman (Editor)
Dataproducts Corp.
1757 Tapo Canyon Road
Simi Valley, CA 93063-3394
Phone: 805-578-4421
Fax: 805-578-4001
EMail: rbergman@dpc.com
Tom Hastings
Xerox Corporation, ESAE-231
701 S. Aviation Blvd.
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
Fax: (303) 924-4662
EMail: harryl@us.ibm.com
Bob Pentecost
Hewlett-Packard Corporation
11311 Chinden Boulevard
Boise, ID 83714
Phone: (208) 396-3312
Fax: (208) 396-4122
EMail: bpenteco@boi.hp.com
Send comments to the printmib WG using the Job Monitoring Project (JMP) Mailing List: jmp@pwg.org
For further information, access the PWG web page under "JMP": http://www.pwg.org/
Other Participants:
Chuck Adams - Tektronix
Keith Carter - IBM Corporation
Angelo Caruso - Xerox
Jeff Copeland - QMS
Andy Davidson - Tektronix
Mabry Dozier - QMS
Lee Farrell - Canon
David Kellerman - Northlake Software
Rick Landau - Digital
Jay Martin - Underscore
Ira McDonald - Xerox
Stuart Rowley - Kyocera
Bob Setterbo - Adobe
Gail Songer - EFI
Mike Timperman - Lexmark
William Wagner - DPI/Osicom
Chris Wellens - Interworking Labs
Rob Whittle - Novell
Don Wright - Lexmark
Lloyd Young - Lexmark
17. Full Copyright Statement โญ
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 ๐
Funding for the RFC Editor function is currently provided by the Internet Society. ๐โจ
๐ฆ where this page comes from
- ietf: rfc2708 1999-11
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms