search

ietf-scim-wg / draft-ietf-scim-events

Working material for the IETF SCIM Events draft
Other
5 stars 3 forks source link

It should be allowed to include touched attributes instead of changed attributes for notice events #31

Closed arietimmerman closed 7 months ago

arietimmerman commented 11 months ago

For events of type notice this is written:

When the event URI ends with notice, the list of attributes changed is provided.

For PUT and even PATCH requests it is not obvious what attributes are really changed because of the request. It is not forbidden to issue and process a request that requests changes that have already been processed. For example, a PATCH request that includes attribute name MAY tries to set it to a value the attribute already has, so the attribute is never really changed.

I think it is better to either replace the word changed for something like touched or explain explicitly that only attributes that have really changed should be included, but that is usually somewhat difficult to implement.

independentid commented 11 months ago

I had intended that only changed attributes be listed.

I think you are trying to assert that a value has been re-asserted which is not something currently in the spec. Is this important to the group?

Phil @.***

On Dec 21, 2023, at 3:14 AM, Arie Timmerman @.***> wrote:

For events of type notice this is written:

When the event URI ends with notice, the list of attributes changed is provided.

For PUT and even PATCH requests it is not obvious what attributes are really changed because of the request. It is not forbidden to issue and process a request that requests changes that have already been processed. For example, a PATCH request that includes attribute name MAY tries to set it to a value the attribute already has, so the attribute is never really changed.

I think it is better to either replace the word changed for something like touched or explain explicitly that only attributes that have really changed should be included, but that is usually somewhat difficult to implement.

— Reply to this email directly, view it on GitHub https://github.com/ietf-scim-wg/draft-ietf-scim-events/issues/31, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFQUXQIECUZVKOYMMDOR6TYKQKZJAVCNFSM6AAAAABA6HNIHKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2TEMRSGQ3TKMI. You are receiving this because you are subscribed to this thread.

independentid commented 7 months ago

I think the definitions in SCIM PUT don't make it easier to inter-operably discern an attribute that has been re-asserted or just "put back". The use case described in the original working group was javascript code retrieving a user resource, allowing update (e.g. on a form) and then blindly putting it back. The WG wanted to keep logic for the client to a minum.

So, I while "changed" may be a bit ambiguous with regards to touched, I don't think we can tighten it up.

I am going to close this for now. This could be an issue to raise in SCIMbis discussions.