Update openid-caep-1_0.md

[ysarig75]

Add an 'unmanaged' option to current_status in device compliance change event.

[martingalloar]

I believe using "unmanaged" here might be confusing, and also from a flow/transitioning perspective can potentially lead to dead end scenarios if the previous status is "unknown".

I'd suggest normalizing into the same value (either "unknown" or "unmanaged") for both previous and current status.

[ysarig75]

@martingalloar previous_status and current_status are not symmetrical. I added unknown to previous_status because it is possible that the transmitter doesn't have information on the previous status to send. For current_status, unknown is not very useful to send as it is not clear what a receiver will do with such a status.

[thomasdarimont]

Since the previous_status is required how about using "unmanaged" as the initial "null" value.
With this we might not need the "unknown" value anymore IMHO.

So a device could transition from (initially) unmanaged -> not-compliant -> compliant -> unmanaged (again once removed / retired).

[ysarig75]

@thomasdarimont The problem is not the transition of the device status (which is communicate using current_status field but the fact that the previous state is currently required and the transmitter doesn't necessarily know what was the previous_state. So a transmitter may send a current_status=compliant and a a month later, the device become unmanaged and the transmitter want to send a current_status=unmanaged signal but at that point, the transmitter may not know what was the previous_state.