[scim] PATCH "Add" Operation with Value Paths

Shelley <randomshelley@gmail.com> Thu, 01 October 2020 17:51 UTC

Return-Path: <randomshelley@gmail.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C4E3A1193 for <scim@ietfa.amsl.com>; Thu, 1 Oct 2020 10:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcj_3Dl-EXJt for <scim@ietfa.amsl.com>; Thu, 1 Oct 2020 10:51:38 -0700 (PDT)
Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF533A1191 for <scim@ietf.org>; Thu, 1 Oct 2020 10:51:37 -0700 (PDT)
Received: by mail-vk1-xa2a.google.com with SMTP id q124so1188891vkb.8 for <scim@ietf.org>; Thu, 01 Oct 2020 10:51:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4s02Sxxp9R7Q64QQoztBbdsuuGXSljZN6YOKtyDeXC4=; b=Rc2CqMi8canrOHxbsjZI+yEC8yxTA2jYwqdHA+l6SEs6gg31+XXzI1kFjFt0GbLZSI utXWtB5qfDjYC7/IFOONpfCFfwnEJzoYsvQO1v//1JWQgtCmyg7JBzeE2uzn3fJFFX4J dmHiYi3Y3zPy1YOSopQxBeOmMs4ZtzDkvvkoMr94kDKwRcEaaEC8b2nt2Caiat9CEp+8 hUQ/KXucX1D22MUWI6A8ZBeaDavnwvB2bSBFM90fg5Z2HCrIFW+wQgcNi6XyElZTGR2C jPT36oF+3V6Was0UWzihoaqZcIYNNnVWVUoz5md3UjdL3Kn8fBTfIhFTKM8H9PHBEECZ 3QKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4s02Sxxp9R7Q64QQoztBbdsuuGXSljZN6YOKtyDeXC4=; b=L8FW9djIZL/DNhLCUWp4mpf0wwIW6GGYLU5mp0J7UwCMnD0d50OlMXSgOR8XjxevHT 7Mphd5Ts30/qKbLYrBubhoMWXh77Fsx8R5X7lGuolp80Rb94//2dYncMOTA8ibC1ArwO arNlOM5chXfUp8MYmagNf1PYgpvZr9vRAu7GUERB+08hTLge9/YQRsQJrhWoUMfRJ6+K 6uuIqJQvDSFxMtx0RaIDzMnOwbgJvYNWelkA6YLX2UL+GONx9VSKIudbgnxuYOF4blg+ RrWTeeE+trb7K8aSIXOq7oSarnxdaQPNPvphYsha7zAnq1x92M96cZ1ggqNOf1yyxFGe CA0w==
X-Gm-Message-State: AOAM532cVWewNJB0FwrGpp+wC9AGaJGnkPxxu0AD7kBpiMz2uR1TT2YY 2Cf2avdKn2GPscaqBNrsUwXco0whts4DIQIPsB5tDOigoSI4Ew==
X-Google-Smtp-Source: ABdhPJzMiE1K1F5xCrUzQoIAqAJsg7yWzBpA9VYkoNwODmzpxUMz6j0rOLGzSWcQdD0NxtIX57tkaLSOwiccKbJd6EE=
X-Received: by 2002:a05:6122:6bb:: with SMTP id r27mr5839311vkq.3.1601574696574; Thu, 01 Oct 2020 10:51:36 -0700 (PDT)
MIME-Version: 1.0
From: Shelley <randomshelley@gmail.com>
Date: Thu, 01 Oct 2020 12:51:25 -0500
Message-ID: <CAGUsYPztoT74qG5v+9TJ6g6g_Xi-JFQKew4bOOqfK6J+d_em3A@mail.gmail.com>
To: scim@ietf.org
Content-Type: multipart/alternative; boundary="000000000000dee3ef05b09faa48"
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/8URtlxfO0WydvVb7WqrABN7eTbU>
Subject: [scim] PATCH "Add" Operation with Value Paths
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2020 17:51:39 -0000

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