Machine-message v3, extend possible values for Type enumeration

[joeyphant]

In order to determine the actual type of the message which was sent by the device, the possible values for the Type enumeration should be extended.

Current values: DEVICE, TECHNICAL_INFO Additional values: DEVICE_INFO, DEVICE_WARNING, DEVICE_ERROR

A device might sent a list of messages where only one is an error and the others only contain informational content

[ameinhardt]

Hi @joeyphant , can severity (HIGH, MEDIUM, LOW) not cover that for you? Or is there a DEVICE_ERROR with severity low and a DEVICE_INFO with severity high in your scenario? The type field does indicated the type of origin (from a device or somewhere in the infrastructure)

[joeyphant]

Hi @ameinhardt, Severity could cover that, yes. But I don't like the idea of having an implicit meaning behind the severity. Different solutions/services using PPMP might have different implicit meanings behind the severity.

Currently our scenario does not support a DEVICE_ERROR with severity low or a DEVICE_INFO with severity high. However, there might be scenarios in the future where this needs to be supported.

Thanks for the clarification of the current usage of the type field. While the usage does not fit my requested changes, the name of the field certainly does. That's why I also included DEVICE_ prefix in all new values.

[muelsen]

Hi @joeyphant , @ameinhardt , I think if we don't have the specific requirement currently we shouldn't add fields we don't need. Better to keep it as simple as needed instead of adding to many options to the enum.

[joeyphant]

@ameinhardt , @muelsen , After clarifying again, there are errors with different severities in our scenario.

[ameinhardt]

Maybe we could rename type to source. Then, type is free for identifying the message type as in ['INFO', 'WARNING', 'ERROR']. severity would still remain. Any objections?

[ameinhardt]

hi @joeyphant, I added your suggestion in the schema. Thanks for the patience