The OMI protocol version will be expressed as a floating point number, such as 1.0, 1.5 etc. Versions less than 1.0 are pre release development versions and are not subject to any control or guarantee of interoperability. Prior to version 1.0 the protocol specification and version may change at will.
Subsequent to 1.0 the protocol specification is controlled. The fractional portion of the version number is referred to as the minor version, and the decimal portions the major version. For example version 1.5 would have a minor version of 5 and a major version of 1. Each protocol change will increment the minor version. In general minor versions shall increment by .01, such as this: 1.0, 1.01, 1.02, 1.03 etc. All protocol versions of the same major version number are guaranteed to be compatible with one another. For example a client application that supports version 1.1 would be able to operate with protocol versions 1.01, 1.2, 1.99, etc. As the version increases additional functionality may be added, or more information added to existing replies. All actions and replies from prior minor versions will be present. All data in replies from prior minor versions will be present, though additional data may be added.
Major versions will be incremented when substantial changes are introduced that result in some version incompatibility. Examples of this are removal of actions or data from replies, the addition of new required information to actions or incompatible changes to existing replies. Interoperability between major versions is not guaranteed.
Clients may request a specific major version by supplying a 'version' parameter in their request. If no version is requested by the client, the default version will be used. Currently this version is 1.10. Versioning request only apply to the major version, as minor version changes are designed to not affect compatibility. Requests for versions greater than the highest supported by the server (upversioning) will be denied with a 102 (Protocol not supported) code. The server may respond to version requests for lower versions (downversioning) in one of three manners. Requests for lower minor versions of the current major version will be silently ignored. Response will be of the current version form and will identify themselves as such. Requests for lower major versions will be honored (if possible) by the server. The server will respond with the requested major version and highest minor version for that major version. If the server cannot honor the requested version an error with a 102 (Protocol not supported) code will be sent. This may occur if a client requests an action not present in the requested version, or if the underlying system now requires new data that is not supplied in the request.
Examples:
Server supports version 1.45, Client requests version 1
Result version 1.45 replies are sent, the same as if no version had been requested.
Server supports version 2.21 and 1.07, Client requests version 1
Result version 1.07 replies will be sent.
Server supports version 3.03, Client requests version 2, with an action not supported in that version.
Result Protocol not supported error returned.
The OMI Protocol supports 2 major versions, 1 and 2. The last minor version of major version 1 is 07, making version 1.07 the last version 1 protocol. Limited downversioning from version 2 is supported. The limits when using version 1 are:
Unless otherwise specified, the OMI server will assume major version 1. This is to allow version 1 client software to continue in use. In order to take advantage of version 2, clients must explicitly request version 2. It is recommended that client software always request a specific OMI version.