rfc2707.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Since each attribute is represented by a row consisting of both the
   jmAttributeValueAsInteger and jmAttributeValueAsOctets MANDATORY
   objects, SNMP requires that the agent SHALL always create an
   attribute row with both objects specified.  However, for most
   attributes the agent SHALL return a "useful" value for one of the



Bergman, et al.              Informational                     [Page 21]

RFC 2707               Job Monitoring MIB - V1.0           November 1999


   objects and SHALL return the 'other' value for the other object.  For
   integer only attributes, the agent SHALL always return a zero-length
   string value for the jmAttributeValueAsOctets object.  For octet
   string only attributes, the agent SHALL always return a '-1' value
   for the jmAttributeValueAsInteger object.

3.3.3 Index Value Attributes

   A number of attributes are indexes in other tables.  Such attribute
   names end with the word 'Index'.  If the agent has not (yet) assigned
   an index value for a particular index attribute for a job, the agent
   SHALL either: (1) return the value 0 or (2) not add this attribute to
   the jmAttributeTable until the index value is assigned.  In the
   interests of brevity, the semantics for 0 is specified once here and
   is not repeated for each index attribute specification and a DEFVAL
   of 0 is implied, even though the DEFVAL for jmAttributeValueAsInteger
   is -2.

3.3.4 Data Sub-types and Attribute Naming Conventions

   Many attributes are sub-typed to give a more specific data type than
   Integer32 or OCTET STRING.  The data sub-type of each attribute is
   indicated on the first line(s) of the description.  Some attributes
   have several different data sub-type representations.  When an
   attribute has both an Integer32 data sub-type and an OCTET STRING
   data sub-type, the attribute can be represented in a single row in
   the jmAttributeTable.  In this case, the data sub-type name is not
   included as the last part of the name of the attribute, e.g.,
   documentFormat(38) which is both an enum and/or a name.  When the
   data sub-types cannot be represented by a single row in the
   jmAttributeTable, each such representation is considered a separate
   attribute and is assigned a separate name and enum value.  For these
   attributes, the name of the data sub-type is the last part of the
   name of the attribute: Name, Index, DateAndTime, TimeStamp, etc.  For
   example, documentFormatIndex(37) is an index.

   NOTE: The Table of Contents also lists the data sub-type and/or data
   sub-types of each attribute, using the textual-convention name when
   such is defined.  The following abbreviations are used in the Table
   of Contents as shown:











Bergman, et al.              Informational                     [Page 22]

RFC 2707               Job Monitoring MIB - V1.0           November 1999


     'Int32(-2..)'     Integer32 (-2..2147483647)
     'Int32(0..)'      Integer32 (0..2147483647)
     'Int32(1..)'      Integer32 (1..2147483647)
     'Int32(m..n)'     For all other Integer ranges, the lower
                       and upper bound of the range is
                       indicated.
     'UTF8String63'    JmUTF8StringTC (SIZE(0..63))
     'JobString63'     JmJobStringTC (SIZE(0..63))
     'Octets63'        OCTET STRING (SIZE(0..63))
     'Octets(m..n)'    For all other OCTET STRING ranges, the
                       exact range is indicated.

3.3.5 Single-Value (Row) Versus Multi-Value (MULTI-ROW) Attributes

   Most attributes have only one row per job.  However, a few attributes
   can have multiple values per job or even per document, where each
   value is a separate row in the jmAttributeTable.  Unless indicated
   with 'MULTI-ROW:' in the JmAttributeTypeTC description, an agent
   SHALL ensure that each attribute occurs only once in the
   jmAttributeTable for a job.  Most of the 'MULTI-ROW' attributes do
   not allow duplicate values, i.e., the agent SHALL ensure that each
   value occurs only once for a job.  Only if the specification of the '
   MULTI-ROW' attribute also says "There is no restriction on the same
   xxx occurring in multiple rows" can the agent allow duplicate values
   to occur for the job.

   NOTE - Duplicates are allowed for 'extensive' 'MULTI-ROW' attributes,
   such as fileName(34) or documentName(35) which are specified to be '
   per-document' attributes, but are not allowed for 'intensive' '
   MULTI-ROW' attributes, such as mediumConsumed(171) and
   documentFormat(38) which are specified to be 'per-job' attributes.

3.3.6 Requested Objects and Attributes

   A number of objects and attributes record requirements for the job.
   Such object and attribute names end with the word 'Requested'.  In
   the interests of brevity, the phrase 'requested' means: (1) requested
   by the client (or intervening server) in the job submission protocol
   and may also mean (2) embedded in the submitted document data, and/or
   (3) defaulted by the recipient device or server with the same
   semantics as if the requester had supplied, depending on
   implementation.  Also if a value is supplied by the job submission
   client, and the server/device determines a better value, through
   processing or other means, the agent MAY return that better value for
   such object and attribute.






Bergman, et al.              Informational                     [Page 23]

RFC 2707               Job Monitoring MIB - V1.0           November 1999


3.3.7 Consumption Attributes

   A number of objects and attributes record consumption.  Such
   attribute names end with the word 'Completed' or 'Consumed'.  If the
   job has not yet consumed what that resource is metering, the agent
   either: (1) SHALL return the value 0 or (2) SHALL not add this
   attribute to the jmAttributeTable until the consumption begins.  In
   the interests of brevity, the semantics for 0 is specified once here
   and is not repeated for each consumption attribute specification and
   a DEFVAL of 0 is implied, even though the DEFVAL for
   jmAttributeValueAsInteger is -2.

3.3.8 Attribute Specifications

   This section specifies the job attributes.

   In the following definitions of the attributes, each description
   indicates whether the useful value of the attribute SHALL be
   represented using the jmAttributeValueAsInteger or the
   jmAttributeValueAsOctets objects by the initial tag: 'INTEGER:' or '
   OCTETS:', respectively.

   Some attributes allow the agent implementer a choice of useful values
   of either an integer, an octet string representation, or both,
   depending on implementation.  These attributes are indicated with '
   INTEGER:' AND/OR 'OCTETS:' tags.

   A very few attributes require both objects at the same time to
   represent a pair of useful values (see mediumConsumed(171)).  These
   attributes are indicated with 'INTEGER:' AND 'OCTETS:' tags.  See the
   jmAttributeGroup for the descriptions of these two MANDATORY objects.

   NOTE - The enum assignments are grouped logically with values
   assigned in groups of 20, so that additional values may be registered
   in the future and assigned a value that is part of their logical
   grouping.

   Values in the range 2**30 to 2**31-1 are reserved for private or
   experimental usage.  This range corresponds to the same range
   reserved in IPP.  Implementers are warned that use of such values may
   conflict with other implementations.  Implementers are encouraged to
   request registration of enum values following the procedures in
   Section 3.7.1.

   NOTE: No attribute name exceeds 31 characters.






Bergman, et al.              Informational                     [Page 24]

RFC 2707               Job Monitoring MIB - V1.0           November 1999


   The standard attribute types are:

    jmAttributeTypeIndex              Datatype
    --------------------              --------

    other(1),                         Integer32 (-2..2147483647)
                                      AND/OR
                                      OCTET STRING(SIZE(0..63))
        INTEGER:  and/or  OCTETS:  An attribute that is not in the
        list and/or that has not been approved and registered with
        the PWG.

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    + Job State attributes (3 - 19 decimal)
    +
    + The following attributes specify the state of a job.
    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    jobStateReasons2(3),              JmJobStateReasons2TC
        INTEGER:  Additional information about the job's current state
        that augments the jmJobState object.  See the description under
        the JmJobStateReasons1TC textual-convention.

    jobStateReasons3(4),              JmJobStateReasons3TC
        INTEGER:  Additional information about the job's current state
        that augments the jmJobState object.  See the description under
        JmJobStateReasons1TC textual-convention.

    jobStateReasons4(5),              JmJobStateReasons4TC
        INTEGER:  Additional information about the job's current state
        that augments the jmJobState object.  See the description under
        JmJobStateReasons1TC textual-convention.

    processingMessage(6),             JmUTF8StringTC (SIZE(0..63))
        OCTETS:  MULTI-ROW:  A coded character set message that is
        generated by the server or device during the processing of the
        job as a simple form of processing log to show progress and any
        problems.  The natural language of each value is specified by
        the corresponding processingMessageNaturalLangTag(7) value.

        NOTE - This attribute is intended for such conditions as
        interpreter messages, rather than being the printable form of
        the jmJobState and jmJobStateReasons1 objects and
        jobStateReasons2, jobStateReasons3, and jobStateReasons4
        attributes.  In order to produce a localized printable form of
        these job state objects/attribute, a management application
        SHOULD produce a message from their enum and bit values.




Bergman, et al.              Informational                     [Page 25]

RFC 2707               Job Monitoring MIB - V1.0           November 1999


        NOTE - There is no job description attribute in IPP/1.0 that
        corresponds to this attribute and this attribute does not
        correspond to the IPP/1.0 'job-state-message' job description
        attribute, which is just a printable form of the IPP 'job-state'
        and 'job-state-reasons' job attributes.

        There is no restriction for the same message occurring in
        multiple rows.

    processingMessageNaturalLangTag(7),   OCTET STRING(SIZE(0..63))
        OCTETS:  MULTI-ROW:  The natural language of the corresponding
        processingMessage(6) attribute value.  See section 3.6.1,
        entitled 'Text generated by the server or device'.

        If the agent does not know the natural language of the job
        processing message, the agent SHALL either (1) return a zero
        length string value for the processingMessageNaturalLangTag(7)
        attribute or (2) not return the
        processingMessageNaturalLangTag(7) attribute for the job.

        There is no restriction for the same tag occurring in multiple
        rows, since when this attribute is implemented, it SHOULD have a
        value row for each corresponding processingMessage(6) attribute
        value row.

    jobCodedCharSet(8),               CodedCharSet
        INTEGER:  The MIBenum identifier of the coded character set that
        the agent is using to represent coded character set objects and
        attributes of type 'JmJobStringTC'.  These coded character set
        objects and attributes are either: (1) supplied by the job
        submitting client or (2) defaulted by the server or device when
        omitted by the job submitting client.  The agent SHALL represent
        these objects and attributes in the MIB either (1) in the coded
        character set as they were submitted or (2) MAY convert the
        coded character set to another coded character set or encoding
        scheme as identified by the jobCodedCharSet(8) attribute.  See
        section 3.6.2, entitled 'Text supplied by the job submitter'.

        These MIBenum values are assigned by IANA [IANA-charsets] when
        the coded character sets are registered.  The coded character
        set SHALL be one of the ones registered with IANA [IANA] and the
        enum value uses the CodedCharSet textual-convention from the
        Printer MIB.  See the JmJobStringTC textual-convention.

        If the agent does not know what coded character set was used by
        the job submitting client, the agent SHALL either (1) return the
        'unknown(2)' value for the jobCodedCharSet(8) attribute or (2)
        not return the jobCodedCharSet(8) attribute for the job.



Bergman, et al.              Informational                     [Page 26]

RFC 2707               Job Monitoring MIB - V1.0