Skip to content

Update openid-caep-1_0.md#329

Open
ysarig75 wants to merge 5 commits into
openid:mainfrom
ysarig75:ysarig75-issue-131
Open

Update openid-caep-1_0.md#329
ysarig75 wants to merge 5 commits into
openid:mainfrom
ysarig75:ysarig75-issue-131

Conversation

@ysarig75

Copy link
Copy Markdown
Contributor

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

Add an 'unmanaged' option to current_status in device compliance change event.
@ysarig75 ysarig75 requested a review from a team as a code owner April 21, 2026 23:00
Comment thread openid-caep-1_0.md Outdated
>
> * `compliant`
> * `not-compliant`
> * `unmanaged`: The device is no longer being managed, and additional compliance change events may not be sent for this device. The device’s compliance state is unknown

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ysarig75, what if the device becomes managed from unmanaged? How would it be represented, as previous_status does not have unmanaged

My alternate proposal is to add a new key current_management_status to the event with the values unknown, managed, unmanaged

This way, we do not need to worry about Tx/Rx that do not know how to process new values in the existing claims.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@appsdesh I like adding current_management_status as you described but we will also need to add unknown to both previous_status and current_status because they are mandatory (you can't just send a current_management_status in a signal).

Comment thread openid-caep-1_0.md Outdated
@appsdesh

Copy link
Copy Markdown
Contributor

@ysarig75 related issue and proposal I had long back here #131

Comment thread openid-caep-1_0.md Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change title to "1.1 - Draft"

Comment thread openid-caep-1_0.md Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we ensure the date is automatically updated? @jischr you had investigated this, right?

@jischr jischr May 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep - remove line 6 and then the date gets automatically populated when the html and xml are built

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants