1.3 Overview

The carrier protocol, as specified in [MS-WMI], is the actual protocol for transferring CIM objects specified in this specification. This specification defines a binary format that is used within the custom marshaling of the Windows Management Instrumentation Remote Protocol (as specified in [MS-WMI]) when CIM objects are being transferred in a protocol operation.

The WMI Remote Protocol is a management protocol for querying status and controlling the settings of real-world managed entities. These entities are modeled by using CIM objects, as specified in [DMTF-DSP0004].

For example, a logical drive might be modeled as a CIM object in which the class of the CIM object is Disk and the various characteristics of the Disk (such as its VolumeLabel, DriveLetter, and the active FileSystem type) are properties in the CIM class. CIM class definitions are thus similar to class definitions in other object-oriented database systems and programming systems.

In the WMI Remote Protocol, each managed entity is assigned a CIM class, and instances of that entity become CIM instances. Continuing with the previous example, the Disk class can contain three instances: one for drive C, one for drive D, and one for drive E.

To query the status of the real-world CIM objects, the WMI Remote Protocol is used to retrieve these instances by using operations such as GetObject or ExecQuery. If updates are required, the WMI Remote Protocol is used to send the updated CIM instance over the wire with the new values. To perform an update, the WMI Remote Protocol writes the complete updated instance, even if only one value is changed. Thus, the WMI Remote Protocol requires an encoding technique of some kind to move CIM objects across the wire when both reading and writing values.

As specified in [DMTF-DSP0004] section 3, CIM classes and instances are defined and illustrated by using the MOF syntax. This is a text-only format for use by tools and in documentation and is not designed for use in a network protocol.

It is not possible to predefine binary layouts for the various types of CIM objects that can be transferred because the system is fully dynamic. New types of classes can be installed and transmitted over the WMI Remote Protocol by vendors and end users, and the full set of CIM object types is not known by the implementation.

This specification defines a binary encoding format as a representation format for CIM objects. When a client application needs to read a CIM class or instance, a GetObject (as specified in [MS-WMI]) operation is performed, and the CIM object is encoded in the definition in this specification. Similarly, if the CIM instance requires updating, the PutInstance operation (as specified in [MS-WMI]) is used, and the updated CIM instance is encoded by using the format in this specification.

The WMI Remote Protocol can read and write both CIM classes and instances of those classes. This specification details how the CIM classes and their instances are encoded for use in the WMI Remote Protocol.

When retrieving CIM objects, the binary encoding that is transmitted over the WMI Remote Protocol has to be decoded. The binary packet is parsed by using Augmented Backus-Naur Form (ABNF) rules in a top-down, recursive descent manner, starting with the root-level grammar rule specified in section 2.2.1. The first octets are examined as the input tokens to the parser, the ABNF rules are examined, and the various branches are taken, consuming the octets until the entire packet is decoded. This is equivalent to LL(1) recursive-descent parsing. For more information, see [AHO-ULLMAN] and numerous compiler textbooks.

For example, ABNF shows that the first nonterminal token is an octet sequence 0x12345678 (the Signature rule). If the first octets match this, the next rule is the ObjectEncodingLength rule, which specifies that the next four octets specify the encoding length of the entire packet. After these octets are consumed, the next octets are examined according to matching rules, using the established convention, as specified in [RFC4234].

When encoding CIM objects for transmission, the ABNF grammar is traversed top-down, and the ABNF grammar rules starting in section 2.2.1 are used to emit the correct octets based on the CIM object that needs to be encoded. Decoding uses the same grammar traversal rules except the existing octet sequence is matched against the grammar token by token.

For example, the rules specify that Signature has to be the first block; so the encoder emits the octet sequence 0x12345678 to match the required rule. Next, the EncodingLength is required. The encoder cannot detect how many octets are required to complete the encoding; so some type of placeholder is established, and the emitter continues, encoding the CIM object using the rules until the CIM object is completely examined and encoded. Next, the encoder has to determine whether the CIM object being encoded is a CIM class or a CIM instance. Then the encoder emits the correct octet value using the ObjectFlags rule. Before this octet is emitted, the encoder has to determine whether the encoded CIM object will contain the server name of origin (the DecServerName rule) and the CIM namespace name (DecNamespaceName). After it is known whether these values will form part of the encoding, the ObjectFlags octet bit values can be set, and the octet can be emitted to the encoding buffer. The rules are traversed for encoding exactly as for decoding, except that the encoder emits the octets instead of recognizing existing octets.

Implementers that use the ABNF grammar (as specified in [RFC4234]) are recommended to be thoroughly familiar with recursive-descent parsing, concepts of terminal and nonterminal productions, LL(1) grammar theory, and code emission techniques with syntax-directed translators. The techniques for the encoding and decoding are thus equivalent to the techniques used by high-level language compilers.