rfc1903.txt

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

StorageType ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "Describes the memory realization of a conceptual row.  A
            row which is volatile(2) is lost upon reboot.  A row which
            is either nonVolatile(3), permanent(4) or readOnly(5), is
            backed up by stable storage.  A row which is permanent(4)
            can be changed but not deleted.  A row which is readOnly(5)
            cannot be changed nor deleted.

            If the value of an object with this syntax is either
            permanent(4) or readOnly(5), it cannot be modified.
            Conversely, if the value is either other(1), volatile(2) or
            nonVolatile(3), it cannot be modified to be permanent(4) or
            readOnly(5).

            Every usage of this textual convention is required to
            specify the columnar objects which a permanent(4) row must
            at a minimum allow to be writable."
    SYNTAX       INTEGER {
                     other(1),       -- eh?
                     volatile(2),    -- e.g., in RAM
                     nonVolatile(3), -- e.g., in NVRAM
                     permanent(4),   -- e.g., partially in ROM
                     readOnly(5)     -- e.g., completely in ROM
                 }


TDomain ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
          "Denotes a kind of transport service.

          Some possible values, such as snmpUDPDomain, are defined in
          'Transport Mappings for Version 2 of the Simple Network
          Management Protocol (SNMPv2)'."



SNMPv2 Working Group        Standards Track                    [Page 18]

RFC 1903             Textual Conventions for SNMPv2         January 1996


    SYNTAX       OBJECT IDENTIFIER


TAddress ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
          "Denotes a transport service address.

          For snmpUDPDomain, a TAddress is 6 octets long, the initial 4
          octets containing the IP-address in network-byte order and the
          last 2 containing the UDP port in network-byte order.  Consult
          'Transport Mappings for Version 2 of the Simple Network
          Management Protocol (SNMPv2)' for further information on
          snmpUDPDomain."
    SYNTAX       OCTET STRING (SIZE (1..255))


END

3.  Mapping of the TEXTUAL-CONVENTION macro

   The TEXTUAL-CONVENTION macro is used to convey the syntax and
   semantics associated with a textual convention.  It should be noted
   that the expansion of the TEXTUAL-CONVENTION macro is something which
   conceptually happens during implementation and not during run-time.

   For all descriptors appearing in an information module, the
   descriptor shall be unique and mnemonic, and shall not exceed 64
   characters in length.  (However, descriptors longer than 32
   characters are not recommended.)  Further, the hyphen is not allowed
   as a character in the name of any textual convention.

3.1.  Mapping of the DISPLAY-HINT clause

   The DISPLAY-HINT clause, which need not be present, gives a hint as
   to how the value of an instance of an object with the syntax defined
   using this textual convention might be displayed.  The DISPLAY-HINT
   clause may be present if and only if the syntax has an underlying
   primitive type of INTEGER or OCTET STRING.  (Note, however, that the
   semantics defined for a particular syntax can cause the use of
   DISPLAY-HINT for that syntax to make no sense, e.g., for Counter32
   [2].)

   When the syntax has an underlying primitive type of INTEGER, the hint
   consists of an integer-format specification, containing two parts.
   The first part is a single character suggesting a display format,
   either: 'x' for hexadecimal, or 'd' for decimal, or 'o' for octal, or
   'b' for binary.  The second part is always omitted for 'x', 'o' and



SNMPv2 Working Group        Standards Track                    [Page 19]

RFC 1903             Textual Conventions for SNMPv2         January 1996


   'b', and need not be present for 'd'.  If present, the second part
   starts with a hyphen and is followed by a decimal number, which
   defines the implied decimal point when rendering the value.  For
   example:

     Hundredths ::= TEXTUAL-CONVENTION
         DISPLAY-HINT "d-2"
         ...
         SYNTAX     INTEGER (0..10000)

   suggests that a Hundredths value of 1234 be rendered as "12.34"

   When the syntax has an underlying primitive type of OCTET STRING, the
   hint consists of one or more octet-format specifications.  Each
   specification consists of five parts, with each part using and
   removing zero or more of the next octets from the value and producing
   the next zero or more characters to be displayed.  The octets within
   the value are processed in order of significance, most significant
   first.

   The five parts of a octet-format specification are:

(1)  the (optional) repeat indicator; if present, this part is a `*',
     and indicates that the current octet of the value is to be used as
     the repeat count.  The repeat count is an unsigned integer (which
     may be zero) which specifies how many times the remainder of this
     octet-format specification should be successively applied.  If the
     repeat indicator is not present, the repeat count is one.

(2)  the octet length: one or more decimal digits specifying the number
     of octets of the value to be used and formatted by this octet-
     specification.  Note that the octet length can be zero.  If less
     than this number of octets remain in the value, then the lesser
     number of octets are used.

(3)  the display format, either:  `x' for hexadecimal, `d' for decimal,
     `o' for octal, or `a' for ascii.  If the octet length part is
     greater than one, and the display format part refers to a numeric
     format, then network-byte ordering (big-endian encoding) is used
     interpreting the octets in the value.

(4)  the (optional) display separator character; if present, this part
     is a single character which is produced for display after each
     application of this octet-specification; however, this character is
     not produced for display if it would be immediately followed by the
     display of the repeat terminator character for this octet-
     specification.  This character can be any character other than a
     decimal digit and a `*'.



SNMPv2 Working Group        Standards Track                    [Page 20]

RFC 1903             Textual Conventions for SNMPv2         January 1996


(5)  the (optional) repeat terminator character, which can be present
     only if the display separator character is present and this octet-
     specification begins with a repeat indicator; if present, this part
     is a single character which is produced after all the zero or more
     repeated applications (as given by the repeat count) of this
     octet-specification.  This character can be any character other
     than a decimal digit and a `*'.

   Output of a display separator character or a repeat terminator
   character is suppressed if it would occur as the last character of
   the display.

   If the octets of the value are exhausted before all the octet-format
   specification have been used, then the excess specifications are
   ignored.  If additional octets remain in the value after interpreting
   all the octet-format specifications, then the last octet-format
   specification is re-interpreted to process the additional octets,
   until no octets remain in the value.

3.2.  Mapping of the STATUS clause

   The STATUS clause, which must be present, indicates whether this
   definition is current or historic.

   The values "current", and "obsolete" are self-explanatory.  The
   "deprecated" value indicates that the definition is obsolete, but
   that an implementor may wish to support the use of this textual
   convention to foster interoperability with older implementations.

3.3.  Mapping of the DESCRIPTION clause

   The DESCRIPTION clause, which must be present, contains a textual
   definition of the textual convention, which provides all semantic
   definitions necessary for implementation, and should embody any
   information which would otherwise be communicated in any ASN.1
   commentary annotations associated with the object.

   Note that, in order to conform to the ASN.1 syntax, the entire value
   of this clause must be enclosed in double quotation marks, and
   therefore cannot itself contain double quotation marks, although the
   value may be multi-line.

3.4.  Mapping of the REFERENCE clause

   The REFERENCE clause, which need not be present, contains a textual
   cross-reference to a related item defined in some other published
   work.




SNMPv2 Working Group        Standards Track                    [Page 21]

RFC 1903             Textual Conventions for SNMPv2         January 1996


3.5.  Mapping of the SYNTAX clause

   The SYNTAX clause, which must be present, defines abstract data
   structure corresponding to the textual convention.  The data
   structure must be one of the alternatives defined in the ObjectSyntax
   CHOICE or the BITS construct (see section 7.1 in [2]).

4.  Security Considerations

   Security issues are not discussed in this memo.

5.  Editor's Address

   Keith McCloghrie
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   US

   Phone: [phone]
   EMail: [e-mail]

6.  Acknowledgements

   This document is the result of significant work by the four major
   contributors:

   Jeffrey D. Case (SNMP Research, [e-mail])
   Keith McCloghrie (Cisco Systems, [e-mail])
   Marshall T. Rose (Dover Beach Consulting, [e-mail])
   Steven Waldbusser (International Network Services, [e-mail])

   In addition, the contributions of the SNMPv2 Working Group are
   acknowledged.  In particular, a special thanks is extended for the
   contributions of:

     Alexander I. Alten (Novell)
     Dave Arneson (Cabletron)
     Uri Blumenthal (IBM)
     Doug Book (Chipcom)
     Kim Curran (Bell-Northern Research)
     Jim Galvin (Trusted Information Systems)
     Maria Greene (Ascom Timeplex)
     Iain Hanson (Digital)
     Dave Harrington (Cabletron)
     Nguyen Hien (IBM)
     Jeff Johnson (Cisco Systems)
     Michael Kornegay (Object Quest)



SNMPv2 Working Group        Standards Track                    [Page 22]

RFC 1903             Textual Conventions for SNMPv2         January 1996


     Deirdre Kostick (AT&T Bell Labs)
     David Levi (SNMP Research)
     Daniel Mahoney (Cabletron)
     Bob Natale (ACE*COMM)
     Brian O'Keefe (Hewlett Packard)
     Andrew Pearson (SNMP Research)
     Dave Perkins (Peer Networks)
     Randy Presuhn (Peer Networks)
     Aleksey Romanov (Quality Quorum)
     Shawn Routhier (Epilogue)
     Jon Saperia (BGS Systems)
     Bob Stewart (Cisco Systems, [e-mail]), chair
     Kaj Tesink (Bellcore)
     Glenn Waters (Bell-Northern Research)
     Bert Wijnen (IBM)

7.  References

[1]  Information processing systems - Open Systems Interconnection -
     Specification of Abstract Syntax Notation One (ASN.1),
     International Organization for Standardization.  International
     Standard 8824, (December, 1987).

[2]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Structure of Management Information for Version 2
     of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
     January 1996.
























SNMPv2 Working Group        Standards Track                    [Page 23]