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

From: Shelley <[email-masked]>
Date: Thu, 1 Oct 2020 12:51:25 -0500

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": ...
}

---

From: Phillip Hunt <[email-masked]>
Date: Thu, 1 Oct 2020 11:29:20 -0700

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 <[email-masked]> 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",
> 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",
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim