Editing XML Management Protocol (section)

=== SMI Type Enhancements ===

Second, we did away with numeric object-identifiers (OIDS) and instance-identifiers (e.g. 1.3.6).  We use the tuple of MIB-name, object-name, and instance-name to uniquely identify an item of management information.  For example, the [http://www.ietf.org/rfc/rfc1213.txt MIB-2] object ''ifInOctets'' for the first network interface is represented by the rather obtuse OID 1.3.6.1.2.1.2.2.1.10.1.  In the XMP SMI, the same MIB object would be represented by the object name ''mib2.ifTable.ifInOctets.if0''.

Third, we added several data types and promoted several textual-conventions.  All numbers are potentially 64-bit.  With BER in the IMF,  changing a number from 32-bits to 64-bits causes a huge impact because both the SMI and protocol implementations much change.  With XML, a longer number is simply transmitted with the implementation being the only component that is potentially impacted.

In the Internet Management Framework, additional semantics are added to base data types through the use of textual conventions which are then treated as quasi-types by MIB specifications and implementers.  Textual conventions pose several problems.  First, they are specified in natural languages (e.g. English) so they are difficult for computers to process on the fly.  Second, they are not technically part of the standard unless they are included in the specification (for example, vendor textual conventions are thus not covered).  Third, they add semantics through overloading which usually results in poor engineering.  One may correctly argue that it is a semantic shell game -- whether semantics are specified by types or by type overloading still requires human involvement to understand the specific semantics.  However, specifying the semantics via types (as opposed to textual conventions) results in a specification that is easier to understand and code.  For the XMP SMI, we promoted several textual conventions to standard type.  Textual-conventions for boolean, IPv6, physical addresses, MAC addresses and date/time stamps were all promoted from textual-convention to standard type.

We added types for IPv6 addresses, and floating points.  Further, we added a ''nullSyntax'' type meant to specify no value or no syntax for a given MIB object thus eliminating confusion over the validity of an object value.  We also added an ''extendedBoolean'' type which lets the agent communicate the values ''true'', ''false'', and ''unknown''.  We also added the type ''unsupportedVariable'' so that an agent could communicate that a particular MIB object was not supported yet could still answer queries about it.  Adding these last two types allows an XMP agent to avoid the cardinal sin of network management which is returning a value for a MIB object that it either does not support or for which it really does not know the value of.
 
The XMP SMI continues to have both scalar and tabular MIB objects.  However, inheritance and other complexities (ala Common Information Model) are strictly avoided.