RFC 2707
Job Monitoring MIB - V1.0
Pages: 114
Informational
Informational
Part 3 of 5 – Pages 51 to 66
3.4 Monitoring Job Progress
There are a number of objects and attributes for monitoring the progress of a job. These objects and attributes count the number of K octets, impressions, sheets, and pages requested or completed. For impressions and sheets, "completed" means stacked, unless the implementation is unable to detect when each sheet is stacked, in which case stacked is approximated when processing of each sheet completes. There are objects and attributes for the overall job and for the current copy of the document currently being stacked. For the latter, the rate at which the various objects and attributes count depends on the sheet and document collation of the job.
Job Collation included sheet collation and document collation. Sheet collation is defined to be the ordering of sheets within a document copy. Document collation is defined to be ordering of document copies within a multi-document job. There are three types of job collation (see terminology definitions in Section 2): 1.uncollatedSheets(3) - No collation of the sheets within each document copy, i.e., each sheet of a document that is to produce multiple copies is replicated before the next sheet in the document is processed and stacked. If the device has an output bin collator, the uncollatedSheets(3) value may actually produce collated sheets as far as the user is concerned (in the output bins). However, when the job collation is the to a monitoring application between a device that has an output bin collator and one that does not. 2.collatedDocuments(4) - Collation of the sheets within each document copy is performed within the printing device by making multiple passes over either the source or an intermediate representation of the document. In addition, when there are multiple documents per job, the i'th copy of each document is stacked before the j'th copy of each document, i.e., the documents are collated within each job copy. For example, if a job is submitted with documents, A and B, the job is made available to the end user as: A, B, A, B, .... The ' collatedDocuments(4)' value corresponds to the IPP [ipp-model] ' separate-documents-collated-copies' value of the "multiple- document-handling" attribute. If jobCopiesRequested or documentCopiesRequested = 1, then jobCollationType is defined as 4. 3.uncollatedDocuments(5) - Collation of the sheets within each document copy is performed within the printing device by making multiple passes over either the source or an intermediate representation of the document. In addition, when there are multiple documents per job, all copies of the first document in the job are stacked before the any copied of the next document in the job, i.e., the documents are uncollated within the job. For example, if a job is submitted with documents, A and B, the job is mad available to the end user as: A, A, ..., B, B, .... The 'uncollatedDocuments(5)' value corresponds to the IPP [ipp-model] 'separate-documents-uncollated-copies' value of the "multiple- document-handling" attribute. Consider the following four variables that are used to monitor the progress of a job's impressions:
1.jmJobImpressionsCompleted - counts the total number of
impressions stacked for the job
2.impressionsCompletedCurrentCopy - counts the number of
impressions stacked for the current document copy
3.sheetCompletedCopyNumber - identifies the number of the copy for
the current document being stacked where the first copy is 1.
4.sheetCompletedDocumentNumber - identifies the current document
within the job that is being stacked where the first document in
a job is 1. NOTE: this attribute SHOULD NOT be implemented for
implementations that only support one document per job.
For each of the three types of job collation, a job with three copies
of two documents (1, 2), where each document consists of 3
impressions, the four variables have the following values as each
sheet is stacked for one-sided printing:
Job Collation Type = uncollatedSheets(3)
jmJobImpressions Impressions sheetCompleted sheetCompleted
Completed CompletedCurrent CopyNumber DocumentNumber
Copy
0 0 0 0
1 1 1 1
2 1 2 1
3 1 3 1
4 2 1 1
5 2 2 1
6 2 3 1
7 3 1 1
8 3 2 1
9 3 3 1
10 1 1 2
11 1 2 2
12 1 3 2
13 2 1 2
14 2 2 2
15 2 3 2
16 3 1 2
17 3 2 2
18 3 3 2
Job Collation Type = collatedDocuments(4)
JmJobImpressions Impressions sheetCompleted sheetCompleted
Completed CompletedCurrent CopyNumber DocumentNumber
Copy
0 0 0 0
1 1 1 1
2 2 1 1
3 3 1 1
4 1 1 2
5 2 1 2
6 3 1 2
7 1 2 1
8 2 2 1
9 3 2 1
10 1 2 2
11 2 2 2
12 3 2 2
13 1 3 1
14 2 3 1
15 3 3 1
16 1 3 2
17 2 3 2
18 3 3 2
Job Collation Type = uncollatedDocuments(5)
jmJobImpressions Impressions sheetCompleted sheetCompleted
Completed CompletedCurrent CopyNumber DocumentNumber
Copy
0 0 0 0
1 1 1 1
2 2 1 1
3 3 1 1
4 1 2 1
5 2 2 1
6 3 2 1
7 1 3 1
8 2 3 1
9 3 3 1
10 1 1 2
11 2 1 2
12 3 1 2
13 1 2 2
14 2 2 2
15 3 2 2
16 1 3 2
17 2 3 2
18 3 3 2
3.5 Job Identification
There are a number of attributes that permit a user, operator or
system administrator to identify jobs of interest, such as jobURI,
jobName, jobOriginatingHost, etc. In addition, there is a
jmJobSubmissionID object that is a text string table index. Being a
table index allows a monitoring application to quickly locate and
identify a particular job of interest that was submitted from a
particular client by the user invoking the monitoring application
without having to scan the entire job table. The Job Monitoring MIB
needs to provide for identification of the job at both sides of the
job submission process. The primary identification point is the
client side. The jmJobSubmissionID allows the monitoring application
to identify the job of interest from all the jobs currently "known"
by the server or device. The value of jmJobSubmissionID can be
assigned by either the client's local system or a downstream server
or device. The point of assignment depends on the job submission
protocol in use.
The server/device-side identifier, called the jmJobIndex object, SHALL be assigned by the SNMP Job Monitoring MIB agent when the server or device accepts the jobs from submitting clients. The jmJobIndex object allows the interested party to obtain all objects desired that relate to a particular job. See Section 3.2, entitled ' The Job Tables and the Oldest Active and Newest Active Indexes' for the specification of how the agent SHALL assign the jmJobIndex values. The MIB provides a mapping table that maps each jmJobSubmissionID value to a corresponding jmJobIndex value generated by the agent, so that an application can determine the correct value for the jmJobIndex value for the job of interest in a single Get operation, given the Job Submission ID. See the jmJobIDGroup. In some configurations there may be more than one application program that monitors the same job when the job passes from one network entity to another when it is submitted. See configuration 3. When there are multiple job submission IDs, each entity MAY supply an appropriate jmJobSubmissionID value. In this case there would be a separate entry in the jmJobSubmissionID table, one for each jmJobSubmissionID. All entries would map to the same jmJobIndex that contains the job data. When the job is deleted, it is up to the agent to remove all entries that point to the job from the jmJobSubmissionID table as well. The jobName attribute provides a name that the user supplies as a job attribute with the job. The jobName attribute is not necessarily unique, even for one user, let alone across users.3.5.1 The Job Submission ID specifications
This section specifies the formats for each of the registered Job Submission Ids. This format is used by the JmJobSubmissionIDTypeTC. Each job submission ID is a fixed-length, 48-octet printable US-ASCII [US-ASCII] coded character string containing no control characters, consisting of the following fields: octet 1: The format letter identifying the format. The US-ASCII characters '0-9', 'A-Z', and 'a-z' are assigned in order giving 62 possible formats. octets 2-40: A 39-character, US-ASCII trailing SPACE filled field specified by the format letter, if the data is less than 39 ASCII characters. octets 41-48: A sequential or random US-ASCII number to make the ID quasi-unique.
If the client does not supply a job submission ID in the job submission protocol, then the agent SHALL assign a job submission ID using any of the standard formats that are reserved for the agent. Clients SHALL not use formats that are reserved for agents and agents SHALL NOT use formats that are reserved for clients, in order to reduce conflicts in ID generation. See the description for which formats are reserved for clients or for agents. Registration of additional formats may be done following the procedures described in Section 3.7.3. The format values defined at the time of completion of this specification are: Format Letter Description ------ ------------ '0' Job Owner generated by the server/device octets 2-40: The last 39 bytes of the jmJobOwner object. octets 41-48: The US-ASCII 8-decimal-digit sequential number assigned by the agent. This format is reserved for agents. NOTE - Clients wishing to use a job submission ID that incorporates the job owner, SHALL use format '8', not format '0'. '1' Job Name octets 2-40: The last 39 bytes of the jobName attribute. octets 41-48: The US-ASCII 8-decimal-digit random number assigned by the client. This format is reserved for clients. '2' Client MAC address octets 2-40: The client MAC address: in hexadecimal with each nibble of the 6 octet address being '0'-'9' or 'A' - 'F' (uppercase only). Most significant octet first. octets 41-48: The US-ASCII 8-decimal-digit sequential number assigned by the client. This format is reserved for clients. '3' Client URL octets 2-40: The last 39 bytes of the client URL [URI-spec]. octets 41-48: The US-ASCII 8-decimal-digit sequential number assigned by the client. This format is reserved for clients.
'4' Job URI
octets 2-40: The last 39 bytes of the URI [URI-spec]
assigned by the server or device to the job when the job
was submitted for processing.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the agent.
This format is reserved for agents.
'5' POSIX User Number
octets 2-40: The last 39 bytes of a user number, such as
POSIX user number.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'6' User Account Number
octets 2-40: The last 39 bytes of the user account number.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'7' DTMF Incoming FAX routing number
octets 2-40: The last 39 bytes of the DTMF incoming FAX
routing number.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'8' Job Owner supplied by the client
octets 2-40: The last 39 bytes of the job owner name (that the
agent returns in the jmJobOwner object).
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients. See format '0' which is
reserved for agents.
'9' Host Name
octets 2-40: The last 39 bytes of the host name with trailing
SPACES that submitted the job to this server/device using
a protocol, such as LPD [RFC1179] which includes the host
name in the job submission protocol.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the job id generated by the submitting
server (configuration 3) or the client (configuration 1
and 2), such as in the LPD protocol.
This format is reserved for clients.
'A' AppleTalk Protocol
octets 2-40: Contains the AppleTalk printer name, with the
first character of the name in octet 2. AppleTalk printer
names are a maximum of 31 characters. Any unused portion
of this field shall be filled with spaces.
octets 41-48: '00000XXX', where 'XXX' is the 3-digit US-ASCII
decimal representation of the Connection Id.
This format is reserved for agents.
'B' NetWare PServer
octets 2-40: Contains the Directory Path Name as recorded by
the Novell File Server in the queue directory. If the
string is less than 40 octets, the left-most character in
the string shall appear in octet position 2. Otherwise,
only the last 39 bytes shall be included. Any unused
portion of this field shall be filled with spaces.
octets 41-48: '000XXXXX' The US-ASCII representation of the
Job Number as per the NetWare File Server Queue Management
Services.
This format is reserved for agents.
'C' Server Message Block protocol (SMB)
octets 2-40: Contains a decimal (US-ASCII coded)
representation of the 16 bit SMB Tree Id field, which
uniquely identifies the connection that submitted the job
to the printer. The most significant digit of the numeric
string shall be placed in octet position 2. All unused
portions of this field shall be filled with spaces. The
SMB Tree Id has a maximum value of 65,535.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the File Handle returned from the device
to the client in response to a Create Print File command.
This format is reserved for agents.
'D' Transport Independent Printer/System Interface (TIP/SI)
octets 2-40: Contains the Job Name from the Job Control-Start
Job (JC-SJ) command. If the Job Name portion is less than
40 octets, the left-most character in the string shall
appear in octet position 2. Any unused portion of this
field shall be filled with spaces. Otherwise, only the
last 39 bytes shall be included.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the jmJobIndex assigned by the agent.
This format is reserved for agents, since the agent supplies
octets 41-48, though the client supplies the job name.
See format '1' reserved to clients to submit job name ids
in which they supply octets 41-48.
'E' IPDS on the MVS or VSE platform
octets 2-40: Contains bytes 2-27 of the XOH Define Group
Boundary Group ID triplet. Octet position 2 MUST carry
the value x'01'. Bytes 28-40 MUST be filled with spaces.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the jmJobIndex assigned by the agent.
This format is reserved for agents, since the agent supplies
octets 41-48, though the client supplies the job name.
'F' IPDS on the VM platform
octets 2-40: Contains bytes 2-31 of the XOH Define Group
Boundary Group ID triplet. Octet position 2 MUST carry
the value x'02'. Bytes 32-40 MUST be filled with spaces.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the jmJobIndex assigned by the agent.
This format is reserved for agents, since the agent supplies
octets 41-48, though the client supplies the file name.
'G' IPDS on the OS/400 platform
octets 2-40: Contains bytes 2-36 of the XOH Define Group
Boundary Group ID triplet. Octet position 2 MUST carry
the value x'03'. Bytes 37-40 MUST be filled with spaces.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the jmJobIndex assigned by the agent.
This format is reserved for agents, since the agent supplies
octets 41-48, though the client supplies the job name.
NOTE - the job submission id is only intended to be unique between a
limited set of clients for a limited duration of time, namely, for
the life time of the job in the context of the server or device that
is processing the job. Some of the formats include something that is
unique per client and a random number so that the same job submitted
by the same client will have a different job submission id. For
other formats, where part of the id is guaranteed to be unique for
each client, such as the MAC address or URL, a sequential number
SHOULD suffice for each client (and may be easier for each client to
manage). Therefore, the length of the job submission id has been
selected to reduce the probability of collision to an extremely low
number, but is not intended to be an absolute guarantee of
uniqueness. None-the-less, collisions are remotely possible, but
without bad consequences, since this MIB is intended to be used only
for monitoring jobs, not for controlling and managing them.
3.6 Internationalization Considerations
This section describes the internationalization considerations
included in this MIB.
3.6.1 Text generated by the server or device
There are a few objects and attributes generated by the server or device that SHALL be represented using the Universal Multiple-Octet Coded Character Set (UCS) [ISO-10646]. These objects and attributes are always supplied (if implemented) by the agent, not by the job submitting client: 1. jmGeneralJobSetName object 2. processingMessage(6) attribute 3. physicalDevice(32) (name value) attribute The character encoding scheme for representing these objects and attributes SHALL be UTF-8 as REQUIRED by RFC 2277 [RFC2277]. The ' JmUTF8StringTC' textual convention is used to indicate UTF-8 text strings. NOTE - For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation of 7-bit ASCII is identical to the US-ASCII [US-ASCII] encoding. The text contained in the processingMessage(6) attribute is generated by the server/device. The natural language for the processingMessage(6) attribute is identified by the processingMessageNaturalLangTag(7) attribute. The processingMessageNaturalLangTag(7) attribute uses the JmNaturalLanguageTagTC textual convention which SHALL conform to the language tag mechanism specified in RFC 1766 [RFC1766]. The JmNaturalLanguageTagTC value is the same as the IPP [ipp-model] ' naturalLanguage' attribute syntax. RFC 1766 specifies that a US- ASCII string consisting of the natural language followed by an optional country field. Both fields use the same two-character codes from ISO 639 [ISO-639] and ISO 3166 [ISO-3166], respectively, that are used in the Printer MIB for identifying language and country. Examples of the values of the processingMessageNaturalLangTag(7) attribute include: 1. 'en' for English 2. 'en-us' for US English 3. 'fr' for French 4. 'de' for German3.6.2 Text supplied by the job submitter
All of the objects and attributes represented by the 'JmJobStringTC' textual-convention are either (1) supplied in the job submission protocol by the client that submits the job to the server or device or (2) are defaulted by the server or device if the job submitting client does not supply values. The agent SHALL represent these
objects and attributes in the MIB either (1) in the coded character set as they were submitted or (2) MAY convert the coded character set to another coded character set or encoding scheme. In any case, the resulting coded character set representation SHOULD be UTF-8 [UTF-8], but SHALL be one in which the code positions from 0 to 31 is not used, 32 to 127 is US-ASCII [US-ASCII], 127 is not unused, and the remaining code positions 128 to 255 represent single-byte or multi- byte graphic characters structured according to ISO 2022 [ISO-2022] or are unused. The coded character set SHALL be one of the ones registered with IANA [IANA] and SHALL be identified by the jobCodedCharSet attribute in the jmJobAttributeTable for the job. If the agent does not know what coded character set was used by the job submitting client, the agent SHALL either (1) return the 'unknown(2)' value for the jobCodedCharSet attribute or (2) not return the jobCodedCharSet attribute for the job. Examples of coded character sets which meet this criteria for use as the value of the jobCodedCharSet job attribute are: US-ASCII [US- ASCII], ISO 8859-1 (Latin-1) [ISO-8859-1], any ISO 8859-n, HP Roman8, IBM Code Page 850, Windows Default 8-bit set, UTF-8 [UTF-8], US-ASCII plus JIS X0208-1990 Japanese [JIS X0208], US-ASCII plus GB2312-1980 PRC Chinese [GB2312]. See the IANA registry of coded character sets [IANA charsets]. Examples of coded character sets which do not meet this criteria are: national 7-bit sets conforming to ISO 646 (except US-ASCII), EBCDIC, and ISO 10646 (Unicode) [ISO-10646]. In order to represent Unicode characters, the UTF-8 [UTF-8] encoding scheme SHALL be used which has been assigned the MIBenum value of '106' by IANA. The jobCodedCharSet attribute uses the imported 'CodedCharSet' textual-convention from the Printer MIB [printmib]. The natural language for attributes represented by the textual- convention JmJobStringTC is identified either (1) by the jobNaturalLanguageTag(9) attribute or is keywords in US-English (as in IPP). A monitoring application SHOULD attempt to localize keywords into the language of the user by means of some lookup mechanism. If the keyword value is not known to the monitoring application, the monitoring application SHOULD assume that the value is in the natural language specified by the job's jobNaturalLanguageTag(9) attribute and SHOULD present the value to its user as is. The jobNaturalLanguageTag(9) attribute value SHALL have the same syntax and semantics as the processingMessageNaturalLangTag(7) attribute, except that the jobNaturalLanguageTag(9) attribute identifies the natural language of
attributes supplied by the job submitter instead of the natural language of the processingMessage(6) attribute. See Section 3.6.1.3.6.3 'DateAndTime' for representing the date and time
This MIB also contains objects that are represented using the DateAndTime textual convention from SMIv2 [SMIv2-TC]. The job management application SHALL display such objects in the locale of the user running the monitoring application.3.7 IANA and PWG Registration Considerations
This MIB does not require any additional registration schemes for IANA, but does depend on registration schemes that other Internet standards track specifications have set up. The names of these IANA registration assignments under the /in-notes/iana/assignments/ path: 1.printer-language-numbers - used as enums in the documentFormat(38) attribute 2.media-types - uses as keywords in the documentFormat(38) attribute 3.character-sets - used as enums in the jobCodedCharSet(8) attribute The Printer Working Group (PWG) will handle registration of additional enums after approving this standard, according to the procedures described in this section:3.7.1 PWG Registration of enums
This specification uses textual conventions to define enumerated values (enums) and bit values. Enumerations (enums) and bit values are sets of symbolic values defined for use with one or more objects or attributes. All enumeration sets and bit value sets are assigned a symbolic data type name (textual convention). As a convention the symbolic name ends in "TC" for textual convention. These enumerations are defined at the beginning of the MIB module specification. The PWG has defined several type of enumerations for use in the Job Monitoring MIB and the Printer MIB [print-mib]. These types differ in the method employed to control the addition of new enumerations. Throughout this document, references to "type n enum", where n can be 1, 2 or 3 can be found in the various tables. The definitions of these types of enumerations are:
3.7.1.1 Type 1 enumerations
Type 1 enumeration: All the values are defined in the Job Monitoring MIB specification (RFC for the Job Monitoring MIB). Additional enumerated values require a new RFC. There are no type 1 enums in the current document.3.7.1.2 Type 2 enumerations
Type 2 enumeration: An initial set of values are defined in the Job Monitoring MIB specification. Additional enumerated values are registered with the PWG. The following type 2 enums are contained in the current document: 1. JmUTF8StringTC 2. JmJobStringTC 3. JmNaturalLanguageTagTC 4. JmTimeStampTC 5. JmFinishingTC [same enum values as IPP "finishing" attribute] 6. JmPrintQualityTC [same enum values as IPP "print-quality" attribute] 7. JmTonerEconomyTC 8. JmMediumTypeTC 9. JmJobSubmissionIDTypeTC 10.JmJobCollationTypeTC 11.JmJobStateTC [same enum values as IPP "job-state" attribute] 12.JmAttributeTypeTC For those textual conventions that have the same enum values as the indicated IPP Job attribute are simultaneously registered by the PWG for use with IPP [ipp-model] and the Job Monitoring MIB.3.7.1.3 Type 3 enumeration
Type 3 enumeration: An initial set of values are defined in the Job Monitoring MIB specification. Additional enumerated values are registered through the PWG without PWG review. There are no type 3 enums in the current document.
3.7.2 PWG Registration of type 2 bit values
This memo contains the following type 2 bit value textual- conventions: 1. JmJobServiceTypesTC 2. JmJobStateReasons1TC 3. JmJobStateReasons2TC 4. JmJobStateReasons3TC 5. JmJobStateReasons4TC These textual-conventions are defined as bits in an Integer so that they can be used with SNMPv1 SMI. The jobStateReasonsN (N=1..4) attributes are defined as bit values using the corresponding JmJobStateReasonsNTC textual-conventions. The registration of JmJobServiceTypesTC and JmJobStateReasonsNTC bit values follow the procedures for a type 2 enum as specified in Section 3.7.1.2.3.7.3 PWG Registration of Job Submission Id Formats
In addition to enums and bit values, this specification assigns a single ASCII digit or letter to various job submission ID formats. See the JmJobSubmissionIDTypeTC textual-convention and the object. The registration of JobSubmissionID format numbers follows the procedures for a type 2 enum as specified in Section 3.7.1.2.3.7.4 PWG Registration of MIME types/sub-types for document-formats
The documentFormat(38) attribute has MIME type/sub-type values for indicating document formats which IANA registers as "media type" names. The values of the documentFormat(38) attribute are the same as the corresponding Internet Printing Protocol (IPP) "document- format" Job attribute values [ipp-model].3.8 Security Considerations
3.8.1 Read-Write objects
All objects are read-only, greatly simplifying the security considerations. If another MIB augments this MIB, that MIB might accept SNMP Write operations to objects in that MIB whose effect is to modify the values of read-only objects in this MIB. However, that MIB SHALL have to support the required access control in order to achieve security, not this MIB.
3.8.2 Read-Only Objects In Other User's Jobs
The security policy of some sites MAY be that unprivileged users can only get the objects from jobs that they submitted, plus a few minimal objects from other jobs, such as the jmJobKOctetsPerCopyRequested and jmJobKOctetsProcessed objects, so that a user can tell how busy a printer is. Other sites MAY allow all unprivileged users to see all objects of all jobs. This MIB does not require, nor does it specify how, such restrictions would be implemented. A monitoring application SHOULD enforce the site security policy with respect to returning information to an unprivileged end user that is using the monitoring application to monitor jobs that do not belong to that user, i.e., the jmJobOwner object in the jmJobTable does not match the user's user name. An operator is a privileged user that would be able to see all objects of all jobs, independent of the policy for unprivileged users.3.9 Notifications
This MIB does not specify any notifications. For simplicity, management applications are expected to poll for status. The jmGeneralJobPersistence and jmGeneralAttributePersistence objects assist an application to determine the polling rate. The resulting network traffic is not expected to be significant.
(next page on part 4)