The PubSub communication parameters defined in Clause 6 provide the settings for mapping information from the Publisher into DataSetMessages, settings to send them in NetworkMessages to the Subscribers and settings to process the DataSetMessages on the Subscriber side.

The error handling for the status codes in DataSetMessage headers and DataSetMessage fields is defined in 6.2.11 and 6.2.4.2. This handling of information flows and status codes assumes that the configuration between Publisher and Subscriber is in sync.

In several combinations of settings for the DataSetMessages and NetworkMessages, a Subscriber is able to process received messages without further knowledge of the Publisher side configuration. But most Subscribers need at least the DataSetMetaData to be able to process the received DataSetMessages.

The Publisher side configuration implies two types of contracts necessary for the Subscriber to process messages. The one type of contract is the DataSetMetaData describing the content of a DataSetMessage. The other type of contract provides the communication settings like the DataSetWriterId or offsets inside NetworkMessages. Both type of contracts provide version information that can be included into the DataSetMessages and NetworkMessages.

Several settings in the contracts have corresponding flags or version fields in the messages and a Subscriber can detect mismatches between the contract and the received messages.

The error handling depends on the Subscriber applications. Subscribers that are configured to process certain DataSetMessages often work with a known contract and they will typically drop messages that do not comply with the contract. At the same time they will try to get an update of the contract and will try to adjust its own settings to the updated contract if this is possible. Some changes may need manual reconfiguration of the Subscriber.

But Subscribers may also work without a known contract or may accept some differences between the contract and the actual message layout without dropping messages.

One exception is the security configuration. A Subscriber shall drop all messages where the configured SecurityMode has a lower number than the received SecurityMode. E.g. if the Subscriber is configured for SecurityMode SIGN it shall drop messages with NONE. A Subscriber may process messages with a higher SecurityMode e.g. it is allowed to process messages with SecurityMode SIGN if it is configured for NONE.