RFC 2708

Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB

๐Ÿ“… published November 1999, from ietf

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 (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:

  1. The information is optional in the Control File. ๐ŸŽ€ The attribute should be included if it's present in the Control File.
  2. 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.
  3. 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:

  1. 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:

  1. 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.
  2. The Job MIB sides attribute uses the integer values "1" and "2". The IPP sides attribute uses three keywords ๐Ÿ”ฅ
  3. 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 ๐Ÿงš
  4. 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 ๐Ÿค“

  1. jmJobKOctetsPerCopyRequested and jmJobKOctetsProcessed are in K octets, while DPA job-total-octets and job-octets-completed are in octets and are 63-bits of significance. so the units are totally different, periodt ๐Ÿ’…
  2. jmJobStateReasons1 is a bit map that can describe up to 31 job state reasons. meanwhile, the DPA job-state-reasons attribute 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 the jobStateReasonsN attributes (see section 4.4) ๐Ÿซถ
  3. 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:

  1. every DPA attribute is tagged to show which coded character set goes with it ๐ŸŒˆ
  2. jobStateReasonsN is 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 DPA job-state-reasons is multi-valued, with each value being an OBJECT IDENTIFIER (OID) ๐Ÿ‘‘
  3. the Job MIB sides attribute is an integer '1' or '2', while the DPA sides attribute has one of six OID values, one of which includes plex ๐Ÿ”ฅ
  4. printerResolutionRequested has x and y resolution and is meant to override the resolution instruction in the document (if there is one). the DPA default-printer-resolution is the same in x and y and only takes effect if the document doesn't have a resolution instruction โœจ
  5. the DPA copy-count attribute is per-document, so the MIB value is the sum of the documents' copy-count values times the job's results-profile.job-copies value ๐Ÿงฎ
  6. the DPA copies-completed attribute is also per-document, so the MIB value is the sum of the documents' copies-completed values times the job's results-profile.job-copies value ๐Ÿงฎ
  7. 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:

  1. some of the NDPS job states must be represented by both a jmJobState and a jmJobStateReasons1 object, or by a jobStateReasonsN attribute (N=2, 3, 4). ๐Ÿซ 
  2. the NDPS job state reasons may be mapped to either the object jmJobStateReasons1 or the attribute jobStateReasonsN (N=2, 3, 4). ๐ŸŒˆ
  3. jmJobKOctetsPerCopyRequested and jmJobKOctetsProcessed are in K octets, while the NDPS ndps-att-job-total-octets and ndps-att-job-octets-completed are in octets and are 63-bits of significance. ๐Ÿงฎ
  4. NDPS octets include the multiplication factor from job and document copies, but the MIB values don't. ๐ŸŽ€
  5. the Job MIB object must be multiplied by the attribute jobCopiesRequested to 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:

  1. 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:

  1. 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
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