RFC 1024 (rfc1024) - Page 3 of 74
HEMS variable definitions
Alternative Format: Original Text Document
RFC 1024 HEMS Definitions October 1987 This memo defines a universal type space. A subset of this type space is expected to be an appropriate type space for any entity (e.g., a gateway or a multi-user host). The type space is divided into required and optional portions. Implementors should implement the required portion of the type space plus that part of the optional type space which is appropriate for their particular entity. One problem with defining a universal type space is that certain interesting objects are not universal, but are instead very machine specific (for example, status registers on specialized hardware). To allow implementors to retrieve such implementation-specific objects using the HEMS system, a special APPLICATION type is reserved for non-standard values. Putting objects in ASN.1 form implies an ability to map to and from ASN.1 format. One of the design goals of this system has been to minimize the amount of ASN.1 compilation required by the query processor to reduce the expense of processing queries at entities. (This implies a certain willingness to force the applications querying entities to be more powerful). We expect that most of the complex mapping will be done when objects are read; most writable objects have a simple format (e.g., an INTEGER, or OCTETSTRING). As a result, we have made a heavy use of the ASN.1 SET type, which allows values to be presented in any order. Applications which require particular fields in an object may use the template structure to specify particular fields to be retrieved, but this still permits the query processor to return the fields in whatever order is convenient. In addition to ease the problems of ASN.1 compilation, query processors are not required to reduce an INTEGER to the minimum number of octets as specified in ASN.1. Applications should be prepared to receive INTEGERs which have leading octets with all zeros or ones. More generally, a design goal of HEMS was to try to limit the data processing done at the entity, and to place the burden of data reduction on the querying application. As a result, the objects presented here are typically counters, or values which the entity has to compute already. Object definitions which require the entity to do data reduction are not supported, although consideration might be given to making them optionally available. Finally, HEMS is required to support access by multiple network management centers or applications. This constraint has some important consequences. First, the SET operation cannot be applied to any Counter, since changing the value of a Counter may impair data acquisition by other centers. More generally, there are questions Partridge & Trewitt
