tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2707

 
 
 

Job Monitoring MIB - V1.0

Part 3 of 5, p. 51 to 66
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 51 
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.

Top      Up      ToC       Page 52 
   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:

Top      Up      ToC       Page 53 
     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

Top      Up      ToC       Page 54 
                  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

Top      Up      ToC       Page 55 
                 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.

Top      Up      ToC       Page 56 
   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.

Top      Up      ToC       Page 57 
   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.

Top      Up      ToC       Page 58 
        '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.

Top      Up      ToC       Page 59 
        '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.

Top      Up      ToC       Page 60 
        '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.

Top      Up      ToC       Page 61 
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 German

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

Top      Up      ToC       Page 62 
   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

Top      Up      ToC       Page 63 
   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:

Top      Up      ToC       Page 64 
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.

Top      Up      ToC       Page 65 
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.

Top      Up      ToC       Page 66 
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 RFC Part