STEP Event Protocol Specification

Following is the specification for the "Simple Text Event Protocol" ("STEP") family of SENSE Event Protocols.

Overview

STEP provides a very simple mechanism to capture simple status of a target entity. It is designed to be used in conjuction with programs that use standard output mechanisms for simple text. Each output line is of the form:

       <code><space><reason>

That is, each line consists of three fields:

	<code>	A numeric string (consisting of only decimal digits) that represents the event code
	<space>	A single space character, used to separate the other two fields
	<reason>	Arbitrary display text that describes the event reason

A line of this form is called an event line in the STEP documentation. Here is an example event line describing an event in which a printer has run out of paper:

       242 Printer out of paper

Here is an example of a sequence of event lines displayed by a program conforming to the STEP event line format; this example shows a laser printer going from a healthy "ready" state to a problem state, then back to a a healthy state:

       111 Ready
       112 Processing
       112 Printing
       342 Printer jam
       242 Cover open
       122 Cover closed
       122 Warming up
       112 Printing

If an event line is displayed such that it does not start with a decimal numeric string, or does not contain a space character immediately after the numeric string, then the text of the line is assumed to be a separate event, but the code for the event is assumed to be the last valid code seen. For example:

       111 Ready
       342 Printer jam
       Cover open
       Cover closed
       Warming up
       112 Printing

In this example, the three lines that do not contain an event code are interpreted such that they have an implicit event code value of "342", since the last event line seen with a valid event code was the line displaying "342 Printer jam".

The standard SENSE publisher sfpstrm may be used as a "back-end" to an existing Unix program or shell script to capture displayed lines and use the contents of those lines to publish the current condition of the entity. The sfpstrm program reads lines from stdin and parses each line to extract the code and reason fields, then sends formatted STEP event messages to the Server on behalf of the Publication specified on the sfpstrm command line.

Event Codes

The <code> field in an event line is a specially structured decimal integer in which certain dimensions of the entity's current status are encoded. This value is structured using the following format:

       <vendor-subcode><condition-subcode>

where

	<vendor-subcode>	A vendor-specific event code.
	<condition-code>	A sequence of one to four digits that express the overall condition of the entity.

Each of these subcodes is a sequence of decimal digits; the two subcodes are concatenated such that the <condition-code> is in the least significant position of the resulting decimal number.

The <vendor-subcode> is optional and may not be present; this code may consist of between zero and seven digits.

The <condition-subcode> consists of a sequence of between one and three digits. Each digit represents the value for one of three different dimensions that express the current overall status of the entity; the definitions of these dimensions are described in the following table:

       <support><health><activity>

The following table lists the meanings of each decimal digit value for each dimension; the table columns are aligned in the order the digits would appear in a complete <condition-subcode> string:

The choices for the Support dimension represent a subset of the categories of "Role Models" as defined in Appendix D of the SNMP Printer MIB (RFC 1759). These categories are defined in an order that indicates an increasing level of operational knowledge about the entity:

Value	Category	Meaning
0	Unknown	Unable to determine the required support
1	None	No support required (entity should be healthy)
2	User	Very low knowledge required
3	Operator	Some knowledge required, not necessarily technical
4	Technician	Special training required, usually on the physical aspects of the entity; for example, Field Service personnel
4	Administrator	special training required, usually dealing with configuration, compatibility or interoperability; for example, System Manager
6-9	(reserved)	Reserved for future definitions

A "persistent" Warning, on the other hand, indicates that the Warning condition will continue until some kind of human intervention takes place. Using a laser printer as an example, this condition would exist when the printer recognizes that its toner supply is low; if the toner is not refilled soon enough, then the printer will transition to a Health value of Alert.

• No way to determine whether the entity is performing useful work
• Can only distinguish between "idle" and "busy"
• Can distinguish between various levels of activity

To be able to unambiguously express these situations, the set of Activity values was partitioned to accommodate these various degrees of capability:

Value	Meaning
0	Unknown; unable to determine activity level
1	Idle; definitely no activity
2	Not idle; some activity is present, but unable to determine any kind of level
3	Low level of activity; within the spectrum of ability to determine an activity level, this implies the least level of activity
4, 5	More than lightly busy
6	Average level of activity; if the level of activity can be measured in some way, then this value represents the mid-point of the range
7, 8	Busier than average
9	As busy as the entity can possibly be without exploding, going on strike, or otherwise punting off into oblivion

Given these definitions for expressing an entity's condition at the time of an event, the following table presents some examples of STEP event code values; each example includes a printer-related problem scenario in which the event code can express useful information to certain types of persons:

Event Messages

tbs