Re: [scim] PATCH "Add" Operation with Value Paths

[Phillip Hunt <[e-mail]>]

Using add instead of replace would not be expected.  So an add with a valuepath filter to a mv attribute would not make sense.  An add of a sub-attribute using a valuepath filter would.  For many implementations you could expect a bad request response. 

As past editor I find it hard to agree it is necessary to document every unexpected behavior (There are 1000s). I caution the members of this list that scim receives significant criticism for *over* specification.  

Still for implementers, I always suggest using “robust” coding approach which means that if you feel you can clearly understand the request you are free to accept it.  Still, likewise clients should be prepared to accept bad request. 

Phil

> On Oct 1, 2020, at 10:51 AM, Shelley <[e-mail]> wrote:
> 
> 
> What is the expected behavior when an "add" operation provides a "path" containing a multi-valued attribute with a value filter?
> 
> In this example, I suppose that any emails that meet the criteria should set/replace their "type" sub-attribute? (Although, I'm not sure why a consumer would choose "add" vs. "replace".)
> {
>     "op": "add",
>     "path": "emails[primary eq false].type",
>     "value": "other"
> }
> 
> In this example, however, I'm not at all sure of the semantic meaning of the filter? Should this be unsupported (resulting in a failure), should the filter itself effectively be ignored (where the enclosed email element is just appended to the emails array as if the filter was not provided), or should this have some other behavior (e.g. some type of attribute merging for elements that match the filter)?
> {
>     "op": "add",
>     "path": "emails[primary eq false]",
>     "value": ...
> }
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim