From nobody Tue Aug 4 05:06:07 2020 Return-Path: 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 588473A0A53 for ; Tue, 4 Aug 2020 05:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_BL=0.001, RCVD_IN_MSPIKE_L3=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mail.ru 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 VNsuFz63bMdq for ; Tue, 4 Aug 2020 05:06:03 -0700 (PDT) Received: from smtp47.i.mail.ru (smtp47.i.mail.ru [94.100.177.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2334A3A0A4F for ; Tue, 4 Aug 2020 05:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=zVg2GnKnck55kzm2ernj7cAnpLZ3m8maDKH2KdBhw4U=; b=WnNohjRjL7bC8khpx83n3YsLi5hZr9/dpFVnrD8b+ROzhF0JbZWop7JYXqaXImKJuTWWD6GoT7GNW8A+R9Ky8RWpJZpYB92rs2FZCzwIef6VHDjVS7YV9lbQbznC+L1EyWQQYlPbQVu6eHl6V5dNtudGyBGSd6AYe4zeqYY9XDA=; Received: by smtp47.i.mail.ru with esmtpa (envelope-from ) id 1k2vhg-0006fp-Qg for scim@ietf.org; Tue, 04 Aug 2020 15:06:01 +0300 To: scim@ietf.org From: Tangui Le Pense Message-ID: <7edb0743-aa25-106d-2627-8619a7dba446@mail.ru> Date: Tue, 4 Aug 2020 15:06:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: smtp47.i.mail.ru; auth=pass smtp.auth=tangui.lepense@mail.ru smtp.mailfrom=tangui.lepense@mail.ru X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9F6142ABD4516DDC533B49C9C6050063227CB9506C76185B9182A05F538085040667F5F1A367C049EF53E30AFCFC6D28FB0A7934F756DDEAF4C4BC2C1C4D8807A X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE72AC9FB60380F23AEEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006375A514678F9DF65078638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FCB999E7E23EECA86D5A202B6D671E303272F355FAA22B0455389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0A3E989B1926288338941B15DA834481FCF19DD082D7633A0E7DDDDC251EA7DABA471835C12D1D977725E5C173C3A84C3643C8550F8485502117882F4460429728AD0CFFFB425014E09623437467D3AE276E601842F6C81A19E625A9149C048EE7532CA1512B819810A5971FBB7557E96D8FC6C240DEA76429449624AB7ADAF37B2D370F7B14D4BC40A6AB1C7CE11FEE33775554D4E35D8F5AD7EC71F1DB88427C4224003CC8364767A15B7713DBEF166A7F4EDE966BC389F9E8FC8737B5C2249066298569814354B089D37D7C0E48F6CCF19DD082D7633A0E7DDDDC251EA7DABAAAE862A0553A39223F8577A6DFFEA7C33389216BB544DE543847C11F186F3C5E7DDDDC251EA7DABCC89B49CDF41148FBC2A4A7A8370ED8B3C9F3DD0FB1AF5EB4E70A05D1297E1BBCB5012B2E24CD356 X-C8649E89: E759685DDA8069D8CC2EBA766CDF6886284EF926C35B02B369564A702495BB6855B84F4C62AE5C43 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojaxgiHk2tpiwZznRr76Hupw== X-Mailru-Sender: 583F1D7ACE8F49BD9992EFD99BFCA8258C7F1F96F909644386591BBE636FC05825CDE588AC211E4BA5D2D6C63D114D6383AFC63A7763B797302201EBD47025992073CDDE12DEC8CD6F486DAF1ACEF02CC676CB43868BEEFB8FF63FEAB625EE02EAB4BC95F72C04283CDA0F3B3F5B9367 X-Mras: Ok Archived-At: Subject: [scim] RFC7644: add operation for PATCH question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 12:06:06 -0000 Hello, RFC7644 states in "3.5.2.1.  Add Operation" that: The operation MUST contain a "value" member whose content specifies the value to be added. The value MAY be a quoted value, or it may be a JSON object containing the sub-attributes of the complex attribute specified in the operation's "path". However, in the first example the value is a list, neither a quoted value nor a JSON object: { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations":[ { "op":"add", "path":"members", "value":[ { "display": "Babs Jensen", "$ref": "https://example.com/v2/Users/2819c223...413861904646", "value": "2819c223-7f76-453a-919d-413861904646" } ] } ] } (The example also appears in "3.5.2.  Modifying with PATCH".) Can you please provide guidance about this? If lists are actually allowed, how to handle it? Also, it's not clear what happens if there's a filter in the path element. It's probably not allowed for adding (only for replacing and removing) but it is not stated in the specification. Regards, -- Tangui From nobody Tue Aug 4 10:40:26 2020 Return-Path: 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 E2B093A0DC5 for ; Tue, 4 Aug 2020 10:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, NICE_REPLY_A=-0.949, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mail.ru 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 8ZlrJDya3Puj for ; Tue, 4 Aug 2020 10:40:21 -0700 (PDT) Received: from smtp54.i.mail.ru (smtp54.i.mail.ru [217.69.128.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9948B3A0DDE for ; Tue, 4 Aug 2020 10:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:References:To:From:Subject; bh=EKTf2IqCfLHssjO21p6pKJHYCIuhL10jnAaHj+t7vDY=; b=cmUzqDQUfoBPHEA7jM9AYRy8TNVDVfKiHNhXtna8t5Wo5b4MdORSHCAGPsraZP8LSFcIsPacnVHyvTCOqDmJLEQTso9ZyNuPSnHUwUyzjP2R0hksJwcJ79lGWy4ZRkxVPi8/SZ/dpivqMDqfdIImxAF77rUrQK3miF1LW9W/618=; Received: by smtp54.i.mail.ru with esmtpa (envelope-from ) id 1k30vA-0008V1-73 for scim@ietf.org; Tue, 04 Aug 2020 20:40:16 +0300 From: Tangui Le Pense To: scim@ietf.org References: <7edb0743-aa25-106d-2627-8619a7dba446@mail.ru> Message-ID: <0b209f8b-cdcd-918e-6ccd-82c38b750aad@mail.ru> Date: Tue, 4 Aug 2020 20:40:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <7edb0743-aa25-106d-2627-8619a7dba446@mail.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: smtp54.i.mail.ru; auth=pass smtp.auth=tangui.lepense@mail.ru smtp.mailfrom=tangui.lepense@mail.ru X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD9F6142ABD4516DDC54D9549387443151A4C427679719D3E33182A05F53808504015636BBCB7A2E34DEA548010D685A69CEC9D7A4931EB18E60B1A230D8EF6D7F0 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7A0175C48BD57B26BC2099A533E45F2D0395957E7521B51C2CFCAF695D4D8E9FCEA1F7E6F0F101C6778DA827A17800CE7BAE5222749FC90208F08D7030A58E5AD6BA297DBC24807EAA9D420A4CFB5DD3EA4E0ACE553D87AC37F5C4EC3872F2DE8ADE7667AABD2F12D8941B15DA834481FA18204E546F3947CEDCF5861DED71B2F389733CBF5DBD5E9C8A9BA7A39EFB7666BA297DBC24807EA117882F446042972877693876707352033AC447995A7AD182CC0D3CB04F14752D2E47CDBA5A96583A67CD397AD5B4748AD7EC71F1DB884274AD6D5ED66289B5278DA827A17800CE7529CEE49F4CD7DA5D32BA5DBAC0009BE395957E7521B51C2E7C897E814753C0B090A508E0FED62991661749BA6B977352A0BF37FED346F29CD04E86FAF290E2DDA63EEEA5E5E9D65089D37D7C0E48F6CA18204E546F3947CDD9D78FC36703085CE5475246E174218C8A9BA7A39EFB7666BA297DBC24807EA089D37D7C0E48F6C8AA50765F790063723E6C16DD8DD76DAEFF80C71ABB335746BA297DBC24807EA27F269C8F02392CDC58410348177836EABEDDA51113D120200306258E7E6ABB4E4A6367B16DE6309 X-C8649E89: FC90F548B7376D8CD154175FC3CFF7A70C0CAC3A62864E55B3A8F3C6CE899AEE71E01576B552B460 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojaxgiHk2tpixeHrdIwhrI/w== X-Mailru-Sender: 583F1D7ACE8F49BD9992EFD99BFCA825DFD50429B3C562E6B35A70D3CEC26550EDFCE13AB0BCBCA8A5D2D6C63D114D6383AFC63A7763B797302201EBD47025992073CDDE12DEC8CD6F486DAF1ACEF02CC676CB43868BEEFB8FF63FEAB625EE02EAB4BC95F72C04283CDA0F3B3F5B9367 X-Mras: Ok Archived-At: Subject: Re: [scim] RFC7644: add operation for PATCH question X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 17:40:24 -0000 Hello, Another inconsistency in the same "3.5.2.1.  Add Operation". The spec says: The value MAY be a quoted value,*or it may be a JSON object containing the sub-attributes of the complex attribute* *specified in the operation's "path".* however the second example of the section is: { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations":[{ "op":"add", "value":{ "emails":[ { "value":"babs@jensen.org", "type":"home" } ], "nickname":"Babs" }] } in which there is no "path". Maybe I misunderstood the term "quoted value", which is not defined anywhere else. Regards, -- Tangui 04.08.2020 15:06, Tangui Le Pense пишет: > Hello, > > RFC7644 states in "3.5.2.1.  Add Operation" that: > >    The operation MUST contain a "value" member whose content specifies >    the value to be added.  The value MAY be a quoted value, or it may be >    a JSON object containing the sub-attributes of the complex attribute >    specified in the operation's "path". > > However, in the first example the value is a list, neither a quoted > value nor a JSON object: > >    { "schemas": >       ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], >      "Operations":[ >        { >         "op":"add", >         "path":"members", >         "value":[ >          { >            "display": "Babs Jensen", >            "$ref": >    "https://example.com/v2/Users/2819c223...413861904646", >            "value": "2819c223-7f76-453a-919d-413861904646" >          } >         ] >        } >      ] >    } > > (The example also appears in "3.5.2.  Modifying with PATCH".) > > Can you please provide guidance about this? If lists are actually > allowed, how to handle it? > > Also, it's not clear what happens if there's a filter in the path > element. It's probably not allowed for adding (only for replacing and > removing) but it is not stated in the specification. > > Regards, > From nobody Thu Aug 13 08:56:47 2020 Return-Path: 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 3CBB03A0E25 for ; Thu, 13 Aug 2020 08:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 PK3vi6V7mpI5 for ; Thu, 13 Aug 2020 08:56:44 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 C13583A0E10 for ; Thu, 13 Aug 2020 08:56:43 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id k25so3141351vsm.11 for ; Thu, 13 Aug 2020 08:56:43 -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=1UDXva+ueJgDPGwq3ChEcoz7Ab3wqxkS37H9sWVseGI=; b=A6ArZGsmn2CMQIwbNqoRkti0Ce78vU/KHftRPlJYa+5qUm3K6RFWJzxVeqAKmxmWUU cdJwoLrj+p5xo18m8QqKYAbWPvDIjgpvc5d5hOApLjjH7CMt3O2sr5pX1aGZ1GMlXJqL 8WLM17a82+atMh6A78pqTw6IY0UXPknGsn2c3s286rQlg9f203x24ChT3fem3lNMrR+y rDyDhrEdevtojOKjTceOk8O3+7a8w03Z4G1CtN9CRK3iowNrcOTM+WnPyWfARA/RZ0xZ EFrXGQatrrkupYttuV8g3dJ4KaU5FMcxjlELs8yJFrC3kXRAbTaVDl3GzXMfChthBd3l spzQ== 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=1UDXva+ueJgDPGwq3ChEcoz7Ab3wqxkS37H9sWVseGI=; b=czyY2K8OKXS6q0opkfvsBKyKFqCJIXWRzbGVW22d3tYnaFXBYLeKacfZ8eeo7mRFYU 20a+DloLjyighcQnKXni9IhahO4UCCOcn+PyAdFp0M4X5nEE9HxIl8grT9sGKBxn5Sm2 XxW/P7qXECNvATivWSfVxbsevY9NqIeTaXqc1J+h2ls/0bX5gGQSc9JZgeJjCuUj7udK ofwTTOQoREUKVoETa8RzchL4I7F2IU1U8nty39oEsVn7urtQQFuV5JM/lH4hi3HuyV7V LwmFGHzLAYx5Sg9YQWMYyQ931WDkWUcEHenMJFfjRQGGzA2yDSI4vfWy0CDhl9CDyv5f q92g== X-Gm-Message-State: AOAM531kqH72rZXIiHv/IERi9R8Fn8//e3HHykphxuYAf1XDsctb9oMy KVWYesKbr5sOIkopMpKcpiszgo0UkBb6iEnQCKpera+B X-Google-Smtp-Source: ABdhPJwf7T884OKWX8IlOFPlQ+xdklsIuIiBjGotgK/Fza4u/ViTg7ZjiFnnyFGHAbzLbl/vUAW2zGgRDckjOMVYD3M= X-Received: by 2002:a67:68d2:: with SMTP id d201mr3866027vsc.186.1597334202442; Thu, 13 Aug 2020 08:56:42 -0700 (PDT) MIME-Version: 1.0 From: Shelley Date: Thu, 13 Aug 2020 10:56:31 -0500 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="000000000000b966c405acc4595f" Archived-At: Subject: [scim] Filter ABNF Clarifications X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 15:56:46 -0000 --000000000000b966c405acc4595f Content-Type: text/plain; charset="UTF-8" While reviewing the SCIM 2.0 filter ABNF syntax [1], I found what appears to be a couple of issues that I wanted to confirm before submitting errata. Regarding the "not" filters: FILTER = attrExp / logExp / valuePath / *1"not" "(" FILTER ")" valFilter = attrExp / logExp / *1"not" "(" valFilter ")" Specifically, if I'm not mistaken: - there should be a space between "not" and "(" - alternatively, the following example [2] *should not *include a space: not (emails co "example.com" or emails.value co "example.org") - the use of "*1" is not correct - this effectively makes the entire rule optional As such, I think the above filters should be re-written as: FILTER = attrExp / logExp / valuePath / "not" [SP] "(" FILTER ")" valFilter = attrExp / logExp / "not" [SP] "(" valFilter ")" In case any SCIM clients/providers are relying on the existing ABNF which does not define the space, the above syntax makes the space optional. Please confirm whether I've misinterpreted anything, otherwise, I will likely report this as errata. [1] https://tools.ietf.org/html/rfc7644#page-21 [2] https://tools.ietf.org/html/rfc7644#page-23 --000000000000b966c405acc4595f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While reviewing the SCIM 2.0 filter ABNF syntax [1], = I found what appears to be a couple of issues that I wanted to confirm befo= re submitting errata.

Regarding the "not&= quot; filters:
     FILTER    =3D attrExp / logExp / valuePat=
h / *1"not" "(" FILTER ")"

     valFilter =3D attrExp / logExp / *1"not" "(" valFi=
lter ")"
Specifically, if I'm not mistaken:
  • there s= hould be a space between "not" and "("
    • alte= rnatively, the following example [2] should not include a space:
      = not (emails co "example.com" or emails.value co "example.org")
  • the use of &qu= ot;*1" is not correct
    • this effectively makes the entire ru= le optional
As such, I think the above filters= should be re-written as:
<= br>
=C2=A0 =C2=A0=C2= =A0 FILTER =C2=A0 =C2=A0=3D attrExp / logExp / valuePath / "not" = [SP] "(" FILTER ")"

=C2=A0 =C2=A0 =C2=A0valFilte= r =3D attrExp / logExp / "not" [SP] "(" valFilter "= ;)"

In case any SCIM clients/providers are relying on= the existing ABNF which does not define the space, the above syntax makes = the space optional.

Please confirm whether I= 've misinterpreted anything, otherwise, I will likely report this as er= rata.

[2] https://tool= s.ietf.org/html/rfc7644#page-23
--000000000000b966c405acc4595f-- From nobody Thu Aug 13 09:27:26 2020 Return-Path: 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 9BC803A0E63 for ; Thu, 13 Aug 2020 09:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.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 0U3cuiAnreJY for ; Thu, 13 Aug 2020 09:27:24 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 4F97D3A0E61 for ; Thu, 13 Aug 2020 09:27:24 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id kr4so3018211pjb.2 for ; Thu, 13 Aug 2020 09:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=vmcloS2cjQaw5x2wHf5iSTWqOL0CSMicPMxPZP35+VU=; b=2OWxMTk9skpOSN74++JCOi5lGuMuNZQlxbOmpN3cx6mOxLhHsQr9jAIXnv6mNKPMX3 znu5sr2XTLSPM47Bt46BLirov5l/JvhAqsAxNWGVvMMVDj0UJR9550ikOuwAbkbfK9ud 8/VoqchCwss5+BbUfUCqPd7NZgyV2egrp1TyCIW60GIToXyN1k+ZMc8fP+/mrEvPVX3p DvN5+DKp5T0GRSpK6aO9DznJOuEJz0wq/4fozKzV+WFrBqEnypv9HohlvqoPBxuJ/X5r WtzofQvD1WDF4weraCMGZ9KcEC+6klMLmSeKmnmq7nOzbWBE1wilr1awpmZgAreTMm+m hEAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=vmcloS2cjQaw5x2wHf5iSTWqOL0CSMicPMxPZP35+VU=; b=UutHrhX3Z5XVejWDY8mnGWyvm3IuJ8h/AO4VXkNi4A63syg18JNtJY5zNJkEkGCrP/ kGJXC7QnyYc7sW7V4mW/b9Q/dHmI4jRDuZ5RPK0Oz9XycAQThbnLGYJc4mvpgvFs6jV1 26nnC9chexig7Npoiiq8w2ClBvX6I9PG1dG9xOD3Xr3ks0NJDbfSGyjllcuJLv6mFUXE 7bEP5UwuGfM3qn3tMCTGPCPLjqeCX+Z2+ZPZpmJGkmH7l5j3jiw4HohFkcoH+ZgiLXUT nSOlDkcsaQ8wjNoQPjvBC8kG0TmClV/e5F3fKPGaHP7A/5qd3y+PV+aXJo6nxn+zH8wf WXpA== X-Gm-Message-State: AOAM530IGLJOrfdQLhqSy/iURlt2a8pM6B1oWMnZM+psGySwXXFW+fn6 ebg0knTazO7NaYwfhhqdkpW9MOJ8jFc= X-Google-Smtp-Source: ABdhPJwY+tIiUjquYYFTsSQIazzCKDl0JeiIFfygiJrdWWxiX4DT3cWNLSWSgEnuQg7zvDQVUqvXdg== X-Received: by 2002:a17:902:9307:: with SMTP id bc7mr4859530plb.213.1597336043398; Thu, 13 Aug 2020 09:27:23 -0700 (PDT) Received: from ?IPv6:2001:569:7a71:1d00:290d:3ee3:97dc:4668? (node-1w7jr9qrfoxx85d1zllo3oig8.ipv6.telus.net. [2001:569:7a71:1d00:290d:3ee3:97dc:4668]) by smtp.gmail.com with ESMTPSA id q5sm5707490pgv.1.2020.08.13.09.27.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Aug 2020 09:27:22 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-33887896-8060-4428-AB04-0C22011C1466 Content-Transfer-Encoding: 7bit From: Phillip Hunt Mime-Version: 1.0 (1.0) Date: Thu, 13 Aug 2020 09:27:22 -0700 Message-Id: <9D2B20FF-64AB-4F6A-8893-9B2CEEE2D87A@independentid.com> References: Cc: scim@ietf.org In-Reply-To: To: Shelley X-Mailer: iPhone Mail (17F80) Archived-At: Subject: Re: [scim] Filter ABNF Clarifications X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 16:27:26 -0000 --Apple-Mail-33887896-8060-4428-AB04-0C22011C1466 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Shelly The =E2=80=9Cnot=E2=80=9D is itself optional to allow bracketing of sub filt= er expressions.=20 (Filter) or not(filter) Phil > On Aug 13, 2020, at 8:56 AM, Shelley wrote: >=20 > =EF=BB=BF > While reviewing the SCIM 2.0 filter ABNF syntax [1], I found what appears t= o be a couple of issues that I wanted to confirm before submitting errata. >=20 > Regarding the "not" filters: > FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER ")" >=20 > valFilter =3D attrExp / logExp / *1"not" "(" valFilter ")" > Specifically, if I'm not mistaken: > there should be a space between "not" and "(" > alternatively, the following example [2] should not include a space: > not (emails co "example.com" or emails.value co "example.org") > the use of "*1" is not correct > this effectively makes the entire rule optional > As such, I think the above filters should be re-written as: >=20 > FILTER =3D attrExp / logExp / valuePath / "not" [SP] "(" FILTER ")= " >=20 > valFilter =3D attrExp / logExp / "not" [SP] "(" valFilter ")" >=20 > In case any SCIM clients/providers are relying on the existing ABNF which d= oes not define the space, the above syntax makes the space optional. >=20 > Please confirm whether I've misinterpreted anything, otherwise, I will lik= ely report this as errata. >=20 > [1] https://tools.ietf.org/html/rfc7644#page-21 > [2] https://tools.ietf.org/html/rfc7644#page-23 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-33887896-8060-4428-AB04-0C22011C1466 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Shelly

The =E2=80=9Cnot=E2= =80=9D is itself optional to allow bracketing of sub filter expressions.&nbs= p;

(Filter) or not(filter)

Phil

O= n Aug 13, 2020, at 8:56 AM, Shelley <randomshelley@gmail.com> wrote:
=EF=BB=BF=
While reviewing the SCIM 2.0 filter ABNF syntax [1], I= found what appears to be a couple of issues that I wanted to confirm before= submitting errata.

Regarding the "not" filters= :
     FILTER    =3D attrExp / logExp / valuePath=
 / *1"not" "(" FILTER ")"

     valFilter =3D attrExp / logExp / *1"not" "(" valFilter ")"
Specifically, if I'm not mistaken:
  • there should= be a space between "not" and "("
    • alternatively, the following e= xample [2] should not include a space:
      not (emails co "example.com" o= r emails.value co "example.org")
  • the use of "*1" is not correct
    • this effectively make= s the entire rule optional
As such, I think the= above filters should be re-written as:

&nbs= p;    FILTER    =3D attrExp / logExp / valuePath / "not"= [SP] "(" FILTER ")"

     valFilter =3D attrExp / logE= xp / "not" [SP] "(" valFilter ")"

In case any SCIM clients/providers are relying on t= he existing ABNF which does not define the space, the above syntax makes the= space optional.

Please confirm whether I've m= isinterpreted anything, otherwise, I will likely report this as errata.
<= /div>

_______________________________________________
scim m= ailing list
scim@ietf.org
https://www.ietf.o= rg/mailman/listinfo/scim
= --Apple-Mail-33887896-8060-4428-AB04-0C22011C1466-- From nobody Thu Aug 13 10:12:21 2020 Return-Path: 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 783F03A0F0C for ; Thu, 13 Aug 2020 10:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 m1W9La99yZ7P for ; Thu, 13 Aug 2020 10:12:19 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 2AAAE3A0F0A for ; Thu, 13 Aug 2020 10:12:19 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id v20so1860108ual.4 for ; Thu, 13 Aug 2020 10:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6ebvkI8lYQtvi3bCeK/M4FqiHq8sAg1uPLAU7oNB2Y8=; b=cpH8hnq6awG48EGB8+oIKFyRel4j2l1w4XGjB5AJTAbQVz+EwMidsagQDa9gSUv8Ru zcbxMvV3vNVQp9MJYQuCpaGJDDyk+zLyA5/ecJwFaN7MRTWVZCpjiqPY+4PuZ2XITqJW UucHI4VOKDhrXlmmINaat1ww8ZBVTHVV2w6/6ScztUN8d7XwRFZmPF3CgN7/AU7Zva0/ IxtlZafrkolmWdqT9X0JPjTgi3G2p+ivQwMuwuFaMyQred1PiqPrWkeHfJc4ia+k2wJe u5gIaUpOAItR2tvqINMpUhl27toyg1dDgwvGsewn5PhXfuE5QNhlHuM6hkZM9n0C+3xZ nYmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6ebvkI8lYQtvi3bCeK/M4FqiHq8sAg1uPLAU7oNB2Y8=; b=eW9UzCX4rj4mhuuHxqgNJoFdrCBM8llNtC86TG1hLTvgtp2N4Q2fQXFDAcqblb9mp5 Tb6ZqtIKdgEJvkrc/Nv0UqQIU+cG0jXgBrt1+VOngCMuOuJefETM2uxqEJ9fIWXUHvDd hzVxQg7u1+5AbonCDbFvAhB6e1tNyWMbYIBSFTBynT3vshA4x8eWgfaDK8+Mx7vNpyAe c2szLzsSzlU/dA5NBa+x0eJDmzXp1lwTTCzpxK15naKrM4OebgE+wgYtsLCB/CaPFmen 52mk3ka7CR0a1ym8KlSaKxQKb0dn+A4XMe0XzNsotYGZawAkF4zuc1ZpYafr1FEbqFgD NXgw== X-Gm-Message-State: AOAM533yXJXqQS8bDH+hVbpS/5m1uptGfHSNayzDUPLZ1wMaWwJMtnwq a/WjqGo3IZyDH2m6BHUKrcdjmsJuPLWO7fEFVPchPxbC X-Google-Smtp-Source: ABdhPJxDPuyUFKvywaQHyQeiMhht6LrpkTHwdy9byaVkubHmR5xMN+OZkam3CERJWrxFKbXyteRXCbqKcsVBrDK69V0= X-Received: by 2002:ab0:c3:: with SMTP id 61mr4319463uaj.106.1597338738200; Thu, 13 Aug 2020 10:12:18 -0700 (PDT) MIME-Version: 1.0 References: <9D2B20FF-64AB-4F6A-8893-9B2CEEE2D87A@independentid.com> In-Reply-To: <9D2B20FF-64AB-4F6A-8893-9B2CEEE2D87A@independentid.com> From: Shelley Date: Thu, 13 Aug 2020 12:12:07 -0500 Message-ID: To: Phillip Hunt Cc: scim@ietf.org Content-Type: multipart/alternative; boundary="00000000000013930405acc56882" Archived-At: Subject: Re: [scim] Filter ABNF Clarifications X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 17:12:20 -0000 --00000000000013930405acc56882 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, thanks for the clarification. I think I better understand the intent behind the "*1" now; this also allows for optional parentheses around any filter expression. I presume the space should still be allowed between the "not" and open parenthesis "(", though? The following updated syntax includes an optional space following the "not", and also includes the recommended parentheses grouping [1] for clarification: FILTER =3D attrExp / logExp / valuePath / ( ["not" *1SP] "(" FILTER ")" ) valFilter =3D attrExp / logExp / ( ["not" *1SP] "(" valFilter ")" ) [1] https://tools.ietf.org/html/rfc5234#section-3.5 On Thu, Aug 13, 2020 at 11:27 AM Phillip Hunt wrote: > Shelly > > The =E2=80=9Cnot=E2=80=9D is itself optional to allow bracketing of sub f= ilter > expressions. > > (Filter) or not(filter) > > Phil > > On Aug 13, 2020, at 8:56 AM, Shelley wrote: > > =EF=BB=BF > While reviewing the SCIM 2.0 filter ABNF syntax [1], I found what appears > to be a couple of issues that I wanted to confirm before submitting errat= a. > > Regarding the "not" filters: > > FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER ")" > > valFilter =3D attrExp / logExp / *1"not" "(" valFilter ")" > > Specifically, if I'm not mistaken: > > - there should be a space between "not" and "(" > - alternatively, the following example [2] *should not *include a > space: > not (emails co "example.com" or emails.value co "example.org") > - the use of "*1" is not correct > - this effectively makes the entire rule optional > > As such, I think the above filters should be re-written as: > > FILTER =3D attrExp / logExp / valuePath / "not" [SP] "(" FILTER "= )" > > valFilter =3D attrExp / logExp / "not" [SP] "(" valFilter ")" > > In case any SCIM clients/providers are relying on the existing ABNF which > does not define the space, the above syntax makes the space optional. > > Please confirm whether I've misinterpreted anything, otherwise, I will > likely report this as errata. > > [1] https://tools.ietf.org/html/rfc7644#page-21 > [2] https://tools.ietf.org/html/rfc7644#page-23 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --00000000000013930405acc56882 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, thanks for the clarification. I think= I better understand the intent behind the "*1" now; this also al= lows for optional parentheses around any filter expression. I presume the s= pace should still be allowed between the "not" and open parenthes= is "(", though? The following updated syntax includes an optional= space following the "not", and also includes the recommended par= entheses grouping [1] for clarification:

=C2=A0 =C2=A0=C2=A0 FILTER =C2=A0 =C2=A0=3D attrExp / logExp / v= aluePath / ( ["not" *1SP] "(" FILTER ")" )
=C2=A0 =C2=A0 =C2=A0valFilter =3D attrExp / logExp / ( ["not"= ; *1SP] "(" valFilter ")" )

=


=
On T= hu, Aug 13, 2020 at 11:27 AM Phillip Hunt <phil.hunt@independentid.com> wrote:
Shelly
<= br>
The =E2=80=9Cnot=E2=80=9D is itself optional to allow bracket= ing of sub filter expressions.=C2=A0

(Filter) or n= ot(filter)

Phil

On Aug 13, 2020, at 8:56 AM, Shelley <= ;randomshelley= @gmail.com> wrote:

=EF=BB=BF
While reviewing the SCIM= 2.0 filter ABNF syntax [1], I found what appears to be a couple of issues = that I wanted to confirm before submitting errata.

=
Regarding the "not" filters:
     FILTER    =3D attrExp / logExp / valuePath / *1"not" &q=
uot;(" FILTER ")"

     valFilter =3D attrExp / logExp / *1"not" "(" valFi=
lter ")"
Specifically, if I'm not mistaken:
  • there s= hould be a space between "not" and "("
    • alte= rnatively, the following example [2] should not include a space:
      = not (emails co "example.com" or emails.value co &= quot;example.org"= )
  • the use of "*1" is not correct
    • = this effectively makes the entire rule optional
As such, I think the above filters should be re-written as:

=C2=A0 =C2=A0=C2=A0 FILTER =C2=A0 =C2=A0=3D attrExp / l= ogExp / valuePath / "not" [SP] "(" FILTER ")"=

=C2=A0 =C2=A0 =C2=A0valFilter =3D attrExp / logExp / "not"= ; [SP] "(" valFilter ")"

In case any SCIM clients/providers are relying on= the existing ABNF which does not define the space, the above syntax makes = the space optional.

Please confirm whether I= 've misinterpreted anything, otherwise, I will likely report this as er= rata.

_______________________________________________
scim = mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/= scim
--00000000000013930405acc56882-- From nobody Thu Aug 13 11:02:37 2020 Return-Path: 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 022C23A1027 for ; Thu, 13 Aug 2020 11:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.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 0BkWDDtwFAG7 for ; Thu, 13 Aug 2020 11:02:33 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 163B03A1025 for ; Thu, 13 Aug 2020 11:02:32 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id bh1so2948493plb.12 for ; Thu, 13 Aug 2020 11:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/BhnHorCkH9ertJgXfdnSWYzFruBJ4Mi1ocAAKltAp0=; b=rfG9SOK9Kn6fhI6UpuQvU5MCoyUz/Hu2jE86SiL60vWBnlOr8FhbkvvyRnSVN4/l3K 3631yx7rNOS3vUNL7ykRZlnmJv3YnTIDml0a8M8emYqfSkjnsLBN8Q605SY4aQIjxgjB Qeqrvad7IiiKjsHtnnfG8zvWex0m0bJAhJ/reNP6OIhCkMwXA5Ay+SGSklIBjX0SdYOg 1mAEv3dq2HpQWJdpRNV0AZ5pq9To5QD06806GtE6GxmBKGjvi0SuoInJstloylnM16ju qVsdRKNnuIb1uVTo72Vw770FEg84EVEtLZPqZYmvX3wWXxeYUQ+XQG9TKFxLq+PQH7hT AOtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/BhnHorCkH9ertJgXfdnSWYzFruBJ4Mi1ocAAKltAp0=; b=nDCjhfx/9NRRB7Zi/lZxU1U92N2bjpYap+inmqfLyfEKkIE5VvEsh6bLCnQlAP5CnN tmhdOwruMjpc1eOYZ8KKerpa8ix5YJ4z890m3gjkl345G5fwqKVd/v0Cxd9TZIjNKOfD itmpORjqekPaPq77cRm+L6pYMqjTO0m8TlxCzX05KgsHUNdVDybQNVgDftb897d/aO5a N4C/3wvmKASlM0eIPzyF59HRw5lz3wVXg574QTijUhSyhUd2Ys/q/1nLCsPZvBKP/VrW Utig9d7y7i8s106JE+BuEUWormc2DxBc2E7W712eZOEqNDO9sKvTwA3ma3l+XuoABcDr uanQ== X-Gm-Message-State: AOAM531RtJr7ZB/zZhOspHza6G3sgKQVjY1MFeEsgWr+pdN6d241dWOx 9MjZ45p+W8nJMDRyIjUGA6OJHQ== X-Google-Smtp-Source: ABdhPJzT1DgcfaViMWkVZK8qpX8AaO7xbrrOVH2x14izK7TQf38VR5GGMD8vdDCphsf6CzSs5zt1Xg== X-Received: by 2002:a17:90a:ff92:: with SMTP id hf18mr6431988pjb.107.1597341752051; Thu, 13 Aug 2020 11:02:32 -0700 (PDT) Received: from node-1w7jr9qrfoxxag5dq472g9k2j.ipv6.telus.net (node-1w7jr9qrfoxxag5dq472g9k2j.ipv6.telus.net. [2001:569:7a71:1d00:c045:8c07:ef46:95db]) by smtp.gmail.com with ESMTPSA id b22sm6924221pfb.213.2020.08.13.11.02.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Aug 2020 11:02:31 -0700 (PDT) From: Phil Hunt Message-Id: <7B069C74-315D-4CCF-8D49-3A6B1B48DF41@independentid.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_388D9653-002E-46ED-A7A5-04A17252B0FB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 13 Aug 2020 11:02:30 -0700 In-Reply-To: Cc: scim@ietf.org To: Shelley References: <9D2B20FF-64AB-4F6A-8893-9B2CEEE2D87A@independentid.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [scim] Filter ABNF Clarifications X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 18:02:35 -0000 --Apple-Mail=_388D9653-002E-46ED-A7A5-04A17252B0FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Shelley, I agree, the ABNF you propose may have been a better way to express = =E2=80=9Cnot=E2=80=9D filters. AFAIK, the iETF does not allow us to make = this kind of RFC update as technically it is a normative change.=20 IMO this would be a good item to address as a clarification item in a = possible future SCIM 2.1 or 3 draft.=20 Phillip Hunt phil.hunt@independentid.com > On Aug 13, 2020, at 10:12 AM, Shelley wrote: >=20 > OK, thanks for the clarification. I think I better understand the = intent behind the "*1" now; this also allows for optional parentheses = around any filter expression. I presume the space should still be = allowed between the "not" and open parenthesis "(", though? The = following updated syntax includes an optional space following the "not", = and also includes the recommended parentheses grouping [1] for = clarification: >=20 > FILTER =3D attrExp / logExp / valuePath / ( ["not" *1SP] "(" = FILTER ")" ) >=20 > valFilter =3D attrExp / logExp / ( ["not" *1SP] "(" valFilter ")" = ) >=20 > [1] https://tools.ietf.org/html/rfc5234#section-3.5 = >=20 >=20 > On Thu, Aug 13, 2020 at 11:27 AM Phillip Hunt = > = wrote: > Shelly >=20 > The =E2=80=9Cnot=E2=80=9D is itself optional to allow bracketing of = sub filter expressions.=20 >=20 > (Filter) or not(filter) >=20 > Phil >=20 >> On Aug 13, 2020, at 8:56 AM, Shelley > wrote: >>=20 >> =EF=BB=BF >> While reviewing the SCIM 2.0 filter ABNF syntax [1], I found what = appears to be a couple of issues that I wanted to confirm before = submitting errata. >>=20 >> Regarding the "not" filters: >> FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER = ")" >>=20 >> valFilter =3D attrExp / logExp / *1"not" "(" valFilter ")" >> Specifically, if I'm not mistaken: >> there should be a space between "not" and "(" >> alternatively, the following example [2] should not include a space: >> not (emails co "example.com " or emails.value co = "example.org ") >> the use of "*1" is not correct >> this effectively makes the entire rule optional >> As such, I think the above filters should be re-written as: >>=20 >> FILTER =3D attrExp / logExp / valuePath / "not" [SP] "(" = FILTER ")" >>=20 >> valFilter =3D attrExp / logExp / "not" [SP] "(" valFilter ")" >>=20 >> In case any SCIM clients/providers are relying on the existing ABNF = which does not define the space, the above syntax makes the space = optional. >>=20 >> Please confirm whether I've misinterpreted anything, otherwise, I = will likely report this as errata. >>=20 >> [1] https://tools.ietf.org/html/rfc7644#page-21 = >> [2] https://tools.ietf.org/html/rfc7644#page-23 = _____________________________= __________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim = --Apple-Mail=_388D9653-002E-46ED-A7A5-04A17252B0FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Shelley,

I = agree, the ABNF you propose may have been a better way to express = =E2=80=9Cnot=E2=80=9D filters. AFAIK, the iETF does not allow us to make = this kind of RFC update as technically it is a normative = change. 

IMO this would be a good item to address as a clarification = item in a possible future SCIM 2.1 or 3 draft. 

Phillip Hunt



On Aug 13, 2020, at 10:12 AM, Shelley <randomshelley@gmail.com> wrote:

OK, thanks for the clarification. = I think I better understand the intent behind the "*1" now; this also = allows for optional parentheses around any filter expression. I presume = the space should still be allowed between the "not" and open parenthesis = "(", though? The following updated syntax includes an optional space = following the "not", and also includes the recommended parentheses = grouping [1] for clarification:

  =    FILTER    =3D attrExp / logExp / valuePath / ( = ["not" *1SP] "(" FILTER ")" )

    =  valFilter =3D attrExp / logExp / ( ["not" *1SP] "(" valFilter ")" = )

[1] = https://tools.ietf.org/html/rfc5234#section-3.5


On Thu, Aug = 13, 2020 at 11:27 AM Phillip Hunt <phil.hunt@independentid.com> wrote:
Shelly
The =E2=80=9Cnot=E2=80=9D= is itself optional to allow bracketing of sub filter = expressions. 

(Filter) or not(filter)

Phil

On Aug 13, 2020, at 8:56 = AM, Shelley <randomshelley@gmail.com> wrote:

=EF=BB=BF
While reviewing the SCIM 2.0 filter ABNF = syntax [1], I found what appears to be a couple of issues that I wanted = to confirm before submitting errata.

Regarding the "not" = filters:
     FILTER    =3D attrExp / logExp / valuePath / =
*1"not" "(" FILTER ")"

     valFilter =3D attrExp / logExp / *1"not" "(" valFilter ")"
Specifically, if I'm not mistaken:
  • there should be a space between = "not" and "("
    • alternatively, the = following example [2] should not include a space:
      not (emails = co "example.com" or emails.value co "example.org")
  • the use of = "*1" is not correct
    • this effectively = makes the entire rule optional
As such, I think the above filters should be re-written = as:

     FILTER =    =3D attrExp / logExp / valuePath / "not" [SP] "(" FILTER = ")"

     valFilter =3D = attrExp / logExp / "not" [SP] "(" valFilter ")"

In case any = SCIM clients/providers are relying on the existing ABNF which does not = define the space, the above syntax makes the space = optional.

Please confirm whether I've misinterpreted anything, = otherwise, I will likely report this as errata.

[1] https://tools.ietf.org/html/rfc7644#page-21
[2] https://tools.ietf.org/html/rfc7644#page-23
_______________________________________________scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

= --Apple-Mail=_388D9653-002E-46ED-A7A5-04A17252B0FB-- From nobody Thu Aug 13 12:14:28 2020 Return-Path: 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 03A5D3A105B for ; Thu, 13 Aug 2020 12:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 aWqaLWBRXwba for ; Thu, 13 Aug 2020 12:14:24 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 44C313A104E for ; Thu, 13 Aug 2020 12:14:24 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id k18so853763uao.11 for ; Thu, 13 Aug 2020 12:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1mjCKwd+4AvzyNM/t+BHQFo5YnQcWNgfWstaneBqg9U=; b=vNVcDcBBaJe7KFzCFIHO9N8ORVJ8RnqnXkbKPWqBKWqJ7uJSVrZgopUALcpXGXRB3M LVxhBJNMFmIxpaKYjfxmQoO9ESHUlsH5+Mt8DdrpJ8d4jDY0dPd6orm5jAfKa+JGwER9 SqJhQ2R1zNEfOqyAgDKikCScGMCN37q9zv71lt2qbsnNXMj+RZpgcviVdWeFvOt2Edpf lKOCnXVydbkeqpwMxT2F2syYeuyAL0jZbBnMg7X98VERSkTce6SI9rz5sVtGp6uL/aX9 bWmPYh6vtRLpdaqwXaZcscANnosjJBW+wORO4KIcn9NJxCyhVpMaIO7k4hjNfMXS5AMA Ctqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1mjCKwd+4AvzyNM/t+BHQFo5YnQcWNgfWstaneBqg9U=; b=q7d965MI5VtNKg2J0N7nnnPa08yVTmYHPmUzFTNUVcGoJni3Luz0jIX7/MNTjmZzj5 dvd2fJ+4br6yjN9wrixTSE4MBGLutYneMkxvLhXoaazm3jNazP10ba8ViJEoRlTnZZ09 ziqABcLKRLXt1ehCuAq2fBcE6ubv85tr4Ll/OG82zhdDqZ7IbM9prRk0y/SavLWMSfsp dIhXC+eDCUh/RXLQ/SD04yPo59tjhUHeymyRxxNokZzUjwMTu4sAPJ5QP5CITCcVlBBc xOD4xeETb2BWto5hKBW7scC3noCwqzL1zmRhoScK3Yr1lj9nodi0y9O7DM5EZRJkZ8qH yvHQ== X-Gm-Message-State: AOAM533XgEHKk3A3GKsDdLM48dEPYOOQ9MBwaALWSw/kHyaKa08Q9i2K MdDuPF4EqRw3q3wi5OSFnntIFze4GtMgZWJ9Dk4= X-Google-Smtp-Source: ABdhPJyb6KnQ3jhXjRHpdzyZptcp9dxkpHn/1kHOKKu7xD87tE36bz9elb2L9oEbKToCzJJl/6Paw8kvvIummC7r1e0= X-Received: by 2002:ab0:5eaa:: with SMTP id y42mr4782929uag.118.1597346063261; Thu, 13 Aug 2020 12:14:23 -0700 (PDT) MIME-Version: 1.0 References: <9D2B20FF-64AB-4F6A-8893-9B2CEEE2D87A@independentid.com> <7B069C74-315D-4CCF-8D49-3A6B1B48DF41@independentid.com> In-Reply-To: <7B069C74-315D-4CCF-8D49-3A6B1B48DF41@independentid.com> From: Shelley Date: Thu, 13 Aug 2020 14:14:12 -0500 Message-ID: To: Phil Hunt Cc: scim@ietf.org Content-Type: multipart/alternative; boundary="000000000000af27f805acc71cd1" Archived-At: Subject: Re: [scim] Filter ABNF Clarifications X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 19:14:27 -0000 --000000000000af27f805acc71cd1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If adding the optional space to the ABNF is not feasible, then perhaps the non-normative example in Figure 2 that includes the space should be updated to remove it? This example [1] is not compliant with the ABNF syntax: not (emails co "example.com" or emails.value co "example.org") Also, is there somewhere that changes like this are being tracked for a future SCIM spec? Thanks for the discussion and clarification regardless [1] https://tools.ietf.org/html/rfc7644#page-23 On Thu, Aug 13, 2020 at 1:02 PM Phil Hunt wrote: > Shelley, > > I agree, the ABNF you propose may have been a better way to express =E2= =80=9Cnot=E2=80=9D > filters. AFAIK, the iETF does not allow us to make this kind of RFC updat= e > as technically it is a normative change. > > IMO this would be a good item to address as a clarification item in a > possible future SCIM 2.1 or 3 draft. > > Phillip Hunt > phil.hunt@independentid.com > > > > On Aug 13, 2020, at 10:12 AM, Shelley wrote: > > OK, thanks for the clarification. I think I better understand the intent > behind the "*1" now; this also allows for optional parentheses around any > filter expression. I presume the space should still be allowed between th= e > "not" and open parenthesis "(", though? The following updated syntax > includes an optional space following the "not", and also includes the > recommended parentheses grouping [1] for clarification: > > FILTER =3D attrExp / logExp / valuePath / ( ["not" *1SP] "(" FILT= ER > ")" ) > > valFilter =3D attrExp / logExp / ( ["not" *1SP] "(" valFilter ")" ) > > [1] https://tools.ietf.org/html/rfc5234#section-3.5 > > > On Thu, Aug 13, 2020 at 11:27 AM Phillip Hunt > wrote: > >> Shelly >> >> The =E2=80=9Cnot=E2=80=9D is itself optional to allow bracketing of sub = filter >> expressions. >> >> (Filter) or not(filter) >> >> Phil >> >> On Aug 13, 2020, at 8:56 AM, Shelley wrote: >> >> =EF=BB=BF >> While reviewing the SCIM 2.0 filter ABNF syntax [1], I found what appear= s >> to be a couple of issues that I wanted to confirm before submitting erra= ta. >> >> Regarding the "not" filters: >> >> FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER ")" >> >> valFilter =3D attrExp / logExp / *1"not" "(" valFilter ")" >> >> Specifically, if I'm not mistaken: >> >> - there should be a space between "not" and "(" >> - alternatively, the following example [2] *should not *include a >> space: >> not (emails co "example.com" or emails.value co "example.org") >> - the use of "*1" is not correct >> - this effectively makes the entire rule optional >> >> As such, I think the above filters should be re-written as: >> >> FILTER =3D attrExp / logExp / valuePath / "not" [SP] "(" FILTER = ")" >> >> valFilter =3D attrExp / logExp / "not" [SP] "(" valFilter ")" >> >> In case any SCIM clients/providers are relying on the existing ABNF whic= h >> does not define the space, the above syntax makes the space optional. >> >> Please confirm whether I've misinterpreted anything, otherwise, I will >> likely report this as errata. >> >> [1] https://tools.ietf.org/html/rfc7644#page-21 >> [2] https://tools.ietf.org/html/rfc7644#page-23 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > --000000000000af27f805acc71cd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If adding the optional space to the ABNF is not feasi= ble, then perhaps the non-normative example in Figure 2 that includes the s= pace should be updated to remove it? This example [1] is not compliant with= the ABNF syntax:
not (emails co "example.com" or emails.value co "example.org")

Also, is there somewhere that changes like this are being tracked for a fut= ure SCIM spec?

Thanks for the discussion and clarification regardless=20


On Thu, Aug 13, 2020 at 1:02 PM Phil Hunt <phil.hunt@independentid.com> wrote:
Shelley,

I agree, the ABNF you propose= may have been a better way to express =E2=80=9Cnot=E2=80=9D filters. AFAIK= , the iETF does not allow us to make this kind of RFC update as technically= it is a normative change.=C2=A0

IMO this would be= a good item to address as a clarification item in a possible future SCIM 2= .1 or 3 draft.=C2=A0

Phillip Hunt

On Aug 13, 2020, at 10:12 AM, Shell= ey <randoms= helley@gmail.com> wrote:

OK, thanks for the clarification. I think I better understand the inte= nt behind the "*1" now; this also allows for optional parentheses= around any filter expression. I presume the space should still be allowed = between the "not" and open parenthesis "(", though? The= following updated syntax includes an optional space following the "no= t", and also includes the recommended parentheses grouping [1] for cla= rification:

=C2=A0 =C2=A0=C2= =A0 FILTER =C2=A0 =C2=A0=3D attrExp / logExp / valuePath / ( ["not&quo= t; *1SP] "(" FILTER ")" )

=C2=A0 =C2=A0 =C2=A0va= lFilter =3D attrExp / logExp / ( ["not" *1SP] "(" valFi= lter ")" )



On Thu, Aug 1= 3, 2020 at 11:27 AM Phillip Hunt <phil.hunt@independentid.com> wrote:
She= lly

The =E2=80=9Cnot=E2=80=9D is itself optional to allo= w bracketing of sub filter expressions.=C2=A0

(Fil= ter) or not(filter)

Phil

On Aug 13, 2020, at 8:56 AM, Sh= elley <rand= omshelley@gmail.com> wrote:

=EF=BB=BF
While reviewing= the SCIM 2.0 filter ABNF syntax [1], I found what appears to be a couple o= f issues that I wanted to confirm before submitting errata.
<= br>
Regarding the "not" filters:
     FILTER    =3D attrExp / logExp / valuePath / *1"not" &q=
uot;(" FILTER ")"

     valFilter =3D attrExp / logExp / *1"not" "(" valFi=
lter ")"
Specifically, if I'm not mistaken:
  • there s= hould be a space between "not" and "("
    • alte= rnatively, the following example [2] should not include a space:
      = not (emails co "example.com" or emails.value co = "example.org&quo= t;)
  • the use of "*1" is not correct
      • this effectively makes the entire rule optional
<= div>As such, I think the above filters should be re-written as:
<= span style=3D"font-family:monospace">
=C2=A0 =C2=A0=C2=A0 FILTER =C2=A0 =C2=A0=3D attrExp /= logExp / valuePath / "not" [SP] "(" FILTER ")&quo= t;

=C2=A0 =C2=A0 =C2=A0valFilter =3D attrExp / logExp / "not&qu= ot; [SP] "(" valFilter ")"

In case any SCIM clients/providers are relying on= the existing ABNF which does not define the space, the above syntax makes = the space optional.

Please confirm whether I= 've misinterpreted anything, otherwise, I will likely report this as er= rata.

_______________________________________________
scim = mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/= scim

--000000000000af27f805acc71cd1-- From nobody Wed Aug 19 07:47:57 2020 Return-Path: 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 C35673A081C for ; Wed, 19 Aug 2020 07:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 VKZcQKLjTs6U for ; Wed, 19 Aug 2020 07:47:54 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 820F93A0A6C for ; Wed, 19 Aug 2020 07:47:39 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id g20so6952966uap.8 for ; Wed, 19 Aug 2020 07:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZujnMWlbgsxUIUJSpyBSX7h35DU1TRGRFBBXPMlAOtw=; b=OuJi1BDBFjbr4K3NBU3fuChKzw49u2KeGMy9Z9928tkMs7fvIyYDGBeFtC/Mb/Eca6 yW6yLCkjLAfEVTtClmxVjvg2MKjGDXZ0nFSpaTrMdUl7EPphlNTAiIHLa7Rzai48EIVw bnYJcyb93mcqX0xPm5TG/8Z8qOVqxYNSF2idrea29fIiwenj6+jIH9FCVO4D776whGpM PqtoXE8h5aZ87xDXiaqCXZW+XzsJNN40hzwqc6wU1ZYDAmz18YSKAcLm+JN04nybyOo0 X7UMXJ4ncupVMcyQ0OTpG4EdgVmB6KoZ7QwO5FAiiy97acOG2exIBX1PtvF4mCh5s7R0 NLOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZujnMWlbgsxUIUJSpyBSX7h35DU1TRGRFBBXPMlAOtw=; b=qhrw21IkvaNKK6Qu4lkbMXHnSrBERGr1cuJfqt9m0DTOM7SFonVkA4RHI1nbaozwrs IMrJVcWhpVK0ryTygicX5Sr2xdY8MqCF8JhydhZGlCJsnzVz7JrXaIotKthi0kNv0480 60rb4adMUnkcAHESmFyfIzjbPNLEk+LJH6vYbnbEeiWu4wu/ctt05r9147yL9gbYrZn8 FkQlUBvOUdNnDLyWn+hyrMcYcp0/uNYnBEkyCSsk75xgEcLU/Va4twWRT/aK9YSTaTzP TPGNiDuthDo6NksqmMjdC4nnMkTyhBcqRrpAyYgFWr4k+9KUPgvD610eb8StEu+7wNds Vtwg== X-Gm-Message-State: AOAM531fsiPxVsuSiE7tm3+IgwcTMT9pImbqm549vL9afM7nE996afKL xPOo2erJgfOBkfa3rohD8TvABdd2u4WtGJyYH218UUEEXOg= X-Google-Smtp-Source: ABdhPJzeoQHppBm74ZpATDdfO7ff89zfvVr5TnblxKlbqopsb/4Ylp1A6pJW05zKpM0IzW1mfzqwpgt+fnzpqJupwT4= X-Received: by 2002:ab0:c3:: with SMTP id 61mr14032219uaj.106.1597848458507; Wed, 19 Aug 2020 07:47:38 -0700 (PDT) MIME-Version: 1.0 References: <9D2B20FF-64AB-4F6A-8893-9B2CEEE2D87A@independentid.com> <7B069C74-315D-4CCF-8D49-3A6B1B48DF41@independentid.com> In-Reply-To: From: Shelley Date: Wed, 19 Aug 2020 09:47:27 -0500 Message-ID: To: Phil Hunt Cc: scim@ietf.org Content-Type: multipart/alternative; boundary="000000000000c63c4a05ad3c155f" Archived-At: Subject: Re: [scim] Filter ABNF Clarifications X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 14:47:56 -0000 --000000000000c63c4a05ad3c155f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There also seems to be a slight discrepancy between the allowed characters in an attribute name between the SCIM Core Schema Specification [1] and the SCIM Protocol Specification [2]. Specifically, the Core Schema ABNF seems to allow "$" characters: ATTRNAME =3D ALPHA *(nameChar) nameChar =3D "$" / "-" / "_" / DIGIT / ALPHA whereas the SCIM filter ABNF does not seem to allow this character in attribute names: ATTRNAME =3D ALPHA *(nameChar) nameChar =3D "-" / "_" / DIGIT / ALPHA Was there any reasoning behind this discrepancy? (In addition, if I'm not mistaken, the "$ref" attribute in the core schema [3] seems to violate the ABNF since it does not start with an ALPHA character. Please let me know if I'm misunderstanding something.) [1] https://tools.ietf.org/html/rfc7643#section-2.1 [2] https://tools.ietf.org/html/rfc7644#page-21 [3] https://tools.ietf.org/html/rfc7643#page-12 On Thu, Aug 13, 2020 at 2:14 PM Shelley wrote: > If adding the optional space to the ABNF is not feasible, then perhaps th= e > non-normative example in Figure 2 that includes the space should be updat= ed > to remove it? This example [1] is not compliant with the ABNF syntax: > not (emails co "example.com" or emails.value co "example.org") > > Also, is there somewhere that changes like this are being tracked for a > future SCIM spec? > > Thanks for the discussion and clarification regardless > > [1] https://tools.ietf.org/html/rfc7644#page-23 > > On Thu, Aug 13, 2020 at 1:02 PM Phil Hunt > wrote: > >> Shelley, >> >> I agree, the ABNF you propose may have been a better way to express =E2= =80=9Cnot=E2=80=9D >> filters. AFAIK, the iETF does not allow us to make this kind of RFC upda= te >> as technically it is a normative change. >> >> IMO this would be a good item to address as a clarification item in a >> possible future SCIM 2.1 or 3 draft. >> >> Phillip Hunt >> phil.hunt@independentid.com >> >> >> >> On Aug 13, 2020, at 10:12 AM, Shelley wrote: >> >> OK, thanks for the clarification. I think I better understand the intent >> behind the "*1" now; this also allows for optional parentheses around an= y >> filter expression. I presume the space should still be allowed between t= he >> "not" and open parenthesis "(", though? The following updated syntax >> includes an optional space following the "not", and also includes the >> recommended parentheses grouping [1] for clarification: >> >> FILTER =3D attrExp / logExp / valuePath / ( ["not" *1SP] "(" FIL= TER >> ")" ) >> >> valFilter =3D attrExp / logExp / ( ["not" *1SP] "(" valFilter ")" ) >> >> [1] https://tools.ietf.org/html/rfc5234#section-3.5 >> >> >> On Thu, Aug 13, 2020 at 11:27 AM Phillip Hunt < >> phil.hunt@independentid.com> wrote: >> >>> Shelly >>> >>> The =E2=80=9Cnot=E2=80=9D is itself optional to allow bracketing of sub= filter >>> expressions. >>> >>> (Filter) or not(filter) >>> >>> Phil >>> >>> On Aug 13, 2020, at 8:56 AM, Shelley wrote: >>> >>> =EF=BB=BF >>> While reviewing the SCIM 2.0 filter ABNF syntax [1], I found what >>> appears to be a couple of issues that I wanted to confirm before submit= ting >>> errata. >>> >>> Regarding the "not" filters: >>> >>> FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER ")= " >>> >>> valFilter =3D attrExp / logExp / *1"not" "(" valFilter ")" >>> >>> Specifically, if I'm not mistaken: >>> >>> - there should be a space between "not" and "(" >>> - alternatively, the following example [2] *should not *include a >>> space: >>> not (emails co "example.com" or emails.value co "example.org") >>> - the use of "*1" is not correct >>> - this effectively makes the entire rule optional >>> >>> As such, I think the above filters should be re-written as: >>> >>> FILTER =3D attrExp / logExp / valuePath / "not" [SP] "(" FILTER= ")" >>> >>> valFilter =3D attrExp / logExp / "not" [SP] "(" valFilter ")" >>> >>> In case any SCIM clients/providers are relying on the existing ABNF >>> which does not define the space, the above syntax makes the space optio= nal. >>> >>> Please confirm whether I've misinterpreted anything, otherwise, I will >>> likely report this as errata. >>> >>> [1] https://tools.ietf.org/html/rfc7644#page-21 >>> [2] https://tools.ietf.org/html/rfc7644#page-23 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>> >>> >> --000000000000c63c4a05ad3c155f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There also seems to be a slight discrepancy between the al= lowed characters in an attribute name between the SCIM Core Schema Specific= ation [1] and the SCIM Protocol Specification [2].

Specifically, the= Core Schema ABNF seems to allow "$" characters:

=C2=A0 =C2=A0ATTRNAME =C2=A0 =3D ALPHA *(nameC= har)
=C2=A0 =C2=A0nameChar =C2=A0 =3D "$" / "-" / &q= uot;_" / DIGIT / ALPHA

whereas the SCIM filter ABNF does= not seem to allow this character in attribute names:

=C2=A0 =C2=A0ATTRNAME =C2=A0=3D ALPHA *(nameChar)=C2=A0 =C2=A0nameChar =C2=A0=3D "-" / "_" / DIGIT / A= LPHA

Was there any reasoning behind this discrepancy?

= (In addition, if I'm not mistaken, the "$ref" attribute in th= e core schema [3] seems to violate the ABNF since it does not start with an= ALPHA character. Please let me know if I'm misunderstanding something.= )

[1] ht= tps://tools.ietf.org/html/rfc7643#section-2.1
[2] https://tools.ietf.org/html/rfc7644#p= age-21
[3] h= ttps://tools.ietf.org/html/rfc7643#page-12

On Thu, Aug 13, 2020 at 2:14 = PM Shelley <randomshelley@gma= il.com> wrote:
If adding the optional space to the ABNF is not= feasible, then perhaps the non-normative example in Figure 2 that includes= the space should be updated to remove it? This example [1] is not complian= t with the ABNF syntax:
not (emails co "example.com" or emails.value co "example.org")

Also, is there somewhere that changes like this are being tracked for a fut= ure SCIM spec?

Thanks for the discussion and clarification regardless=20


On Thu, Aug 13, 2020 at 1:02 PM Phil Hunt <phil.hunt@independentid.com&g= t; wrote:
S= helley,

I agree, the ABNF you propose may have been a be= tter way to express =E2=80=9Cnot=E2=80=9D filters. AFAIK, the iETF does not= allow us to make this kind of RFC update as technically it is a normative = change.=C2=A0

IMO this would be a good item to add= ress as a clarification item in a possible future SCIM 2.1 or 3 draft.=C2= =A0

Phillip Hunt

On Aug 13, 2020, at 10:12 AM, Shell= ey <randoms= helley@gmail.com> wrote:

OK, thanks for the clarification. I think I better understand the inte= nt behind the "*1" now; this also allows for optional parentheses= around any filter expression. I presume the space should still be allowed = between the "not" and open parenthesis "(", though? The= following updated syntax includes an optional space following the "no= t", and also includes the recommended parentheses grouping [1] for cla= rification:

=C2=A0 =C2=A0=C2= =A0 FILTER =C2=A0 =C2=A0=3D attrExp / logExp / valuePath / ( ["not&quo= t; *1SP] "(" FILTER ")" )

=C2=A0 =C2=A0 =C2=A0va= lFilter =3D attrExp / logExp / ( ["not" *1SP] "(" valFi= lter ")" )



On Thu, Aug 1= 3, 2020 at 11:27 AM Phillip Hunt <phil.hunt@independentid.com> wrote:
She= lly

The =E2=80=9Cnot=E2=80=9D is itself optional to allo= w bracketing of sub filter expressions.=C2=A0

(Fil= ter) or not(filter)

Phil

On Aug 13, 2020, at 8:56 AM, Sh= elley <rand= omshelley@gmail.com> wrote:

=EF=BB=BF
While reviewing= the SCIM 2.0 filter ABNF syntax [1], I found what appears to be a couple o= f issues that I wanted to confirm before submitting errata.
<= br>
Regarding the "not" filters:
     FILTER    =3D attrExp / logExp / valuePath / *1"not" &q=
uot;(" FILTER ")"

     valFilter =3D attrExp / logExp / *1"not" "(" valFi=
lter ")"
Specifically, if I'm not mistaken:
  • there s= hould be a space between "not" and "("
    • alte= rnatively, the following example [2] should not include a space:
      = not (emails co "example.com" or emails.value co = "example.org&quo= t;)
  • the use of "*1" is not correct
      • this effectively makes the entire rule optional
<= div>As such, I think the above filters should be re-written as:
<= span style=3D"font-family:monospace">
=C2=A0 =C2=A0=C2=A0 FILTER =C2=A0 =C2=A0=3D attrExp /= logExp / valuePath / "not" [SP] "(" FILTER ")&quo= t;

=C2=A0 =C2=A0 =C2=A0valFilter =3D attrExp / logExp / "not&qu= ot; [SP] "(" valFilter ")"

In case any SCIM clients/providers are relying on= the existing ABNF which does not define the space, the above syntax makes = the space optional.

Please confirm whether I= 've misinterpreted anything, otherwise, I will likely report this as er= rata.

_______________________________________________
scim = mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/= scim

--000000000000c63c4a05ad3c155f-- From nobody Wed Aug 19 10:20:54 2020 Return-Path: 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 9BC923A08DC for ; Wed, 19 Aug 2020 10:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.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 F8vrcWgz6X6H for ; Wed, 19 Aug 2020 10:20:49 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 DF1613A08C3 for ; Wed, 19 Aug 2020 10:20:49 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id r4so11144625pls.2 for ; Wed, 19 Aug 2020 10:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=F9aUpyMqpZWHDtTAnjf132XJutX4qz/MsEb2lON8ks4=; b=cj4lQ1O8KonzYOGcLoNaGT2SShxVqF3wVABa6KdHqPd2DT+iG1l8/v2DzHkwgt0W8t YBVQhvbriA1F/WBebFjfT/Vo4YqsP/X1mILhMHEdHrY337pvhg1tgehVDYI0NjMv+KzE FwwJplixsWvvo0Xc+4eR/JouANYURf9h0OkX9p269y6z06o4uBjWrTl+KkdKOkwwc3op fNZ/ID274+5h9vxqnfQ89zZkunX3DHhbXYofhdh14D1MyTBkJxgngSuSJBQfK3WEfzoI cSP4gDPl8/17pxujscM9VHIfvF/rC1x92KGWuSlMvNaWS26ltPaHhY7IK++6bJk6thlk esag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=F9aUpyMqpZWHDtTAnjf132XJutX4qz/MsEb2lON8ks4=; b=lptfZYqtSM95GnBiDhCLbqDt4F83BvgSQSVYiqlBGocrbEesnqejqskx9U7ErFsGkb eI8aV87uSHddBPgGNjPBApRtca4R2YEMNaQvEfkV06WfS0gedYAYb9vNEyWLM3TgvqTL ww3xsar3tKlksFW/lbFe2h2kYyFvvtbOxb3dl7G5Ax7BcRXdboAxtV0BAi0YrA/zK9C+ FZyJklcZngQ1AXlqjco+FKyjq0MfLKNyXlA4WDojoZ8D6cBoYaC3vbQSN70D0ux3GSt7 1ysQ0Tgj/oqKaYAHI/7/Md+z0zjPb+o2u2RpB57xiKoPzhqY1yOXNNQoZj2H2auuWugG EMMQ== X-Gm-Message-State: AOAM530mgyzLK1SdzWm5lgfz+qhdUOzOpmBpni6c02ZvF4oi4d5zcCDA EXkTYMvoO5KNuniiRkikP4pOUg== X-Google-Smtp-Source: ABdhPJwaaxqkNg0carCEajCo2WSpH7yEReVhZZfUaUGswcQ8Bzc446u7SGV57LRpdXQ43z9jrlbIqg== X-Received: by 2002:a17:902:9349:: with SMTP id g9mr19786581plp.313.1597857649093; Wed, 19 Aug 2020 10:20:49 -0700 (PDT) Received: from node-1w7jr9qrfoxx7w7mld969daxl.ipv6.telus.net (node-1w7jr9qrfoxx7w7mld969daxl.ipv6.telus.net. [2001:569:7a71:1d00:1856:3762:a36d:c999]) by smtp.gmail.com with ESMTPSA id s4sm28799049pfh.128.2020.08.19.10.20.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Aug 2020 10:20:48 -0700 (PDT) From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2472C4AF-2648-4507-B14B-705EFACC9909" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 19 Aug 2020 10:20:47 -0700 In-Reply-To: Cc: scim@ietf.org To: Shelley References: <9D2B20FF-64AB-4F6A-8893-9B2CEEE2D87A@independentid.com> <7B069C74-315D-4CCF-8D49-3A6B1B48DF41@independentid.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [scim] Filter ABNF Clarifications X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 17:20:52 -0000 --Apple-Mail=_2472C4AF-2648-4507-B14B-705EFACC9909 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Shelley Good catch. I would put in an errata for the filter ABNF. Phillip Hunt phil.hunt@independentid.com > On Aug 19, 2020, at 7:47 AM, Shelley wrote: >=20 > There also seems to be a slight discrepancy between the allowed = characters in an attribute name between the SCIM Core Schema = Specification [1] and the SCIM Protocol Specification [2]. >=20 > Specifically, the Core Schema ABNF seems to allow "$" characters: >=20 > ATTRNAME =3D ALPHA *(nameChar) > nameChar =3D "$" / "-" / "_" / DIGIT / ALPHA >=20 > whereas the SCIM filter ABNF does not seem to allow this character in = attribute names: >=20 > ATTRNAME =3D ALPHA *(nameChar) > nameChar =3D "-" / "_" / DIGIT / ALPHA >=20 > Was there any reasoning behind this discrepancy? >=20 > (In addition, if I'm not mistaken, the "$ref" attribute in the core = schema [3] seems to violate the ABNF since it does not start with an = ALPHA character. Please let me know if I'm misunderstanding something.) >=20 > [1] https://tools.ietf.org/html/rfc7643#section-2.1 = > [2] https://tools.ietf.org/html/rfc7644#page-21 = > [3] https://tools.ietf.org/html/rfc7643#page-12 = > On Thu, Aug 13, 2020 at 2:14 PM Shelley > wrote: > If adding the optional space to the ABNF is not feasible, then perhaps = the non-normative example in Figure 2 that includes the space should be = updated to remove it? This example [1] is not compliant with the ABNF = syntax: > not (emails co "example.com " or emails.value co = "example.org ") >=20 > Also, is there somewhere that changes like this are being tracked for = a future SCIM spec? >=20 > Thanks for the discussion and clarification regardless >=20 > [1] https://tools.ietf.org/html/rfc7644#page-23 = > On Thu, Aug 13, 2020 at 1:02 PM Phil Hunt > wrote: > Shelley, >=20 > I agree, the ABNF you propose may have been a better way to express = =E2=80=9Cnot=E2=80=9D filters. AFAIK, the iETF does not allow us to make = this kind of RFC update as technically it is a normative change.=20 >=20 > IMO this would be a good item to address as a clarification item in a = possible future SCIM 2.1 or 3 draft.=20 >=20 > Phillip Hunt > phil.hunt@independentid.com >=20 >=20 >=20 >> On Aug 13, 2020, at 10:12 AM, Shelley > wrote: >>=20 >> OK, thanks for the clarification. I think I better understand the = intent behind the "*1" now; this also allows for optional parentheses = around any filter expression. I presume the space should still be = allowed between the "not" and open parenthesis "(", though? The = following updated syntax includes an optional space following the "not", = and also includes the recommended parentheses grouping [1] for = clarification: >>=20 >> FILTER =3D attrExp / logExp / valuePath / ( ["not" *1SP] "(" = FILTER ")" ) >>=20 >> valFilter =3D attrExp / logExp / ( ["not" *1SP] "(" valFilter = ")" ) >>=20 >> [1] https://tools.ietf.org/html/rfc5234#section-3.5 = >>=20 >>=20 >> On Thu, Aug 13, 2020 at 11:27 AM Phillip Hunt = > = wrote: >> Shelly >>=20 >> The =E2=80=9Cnot=E2=80=9D is itself optional to allow bracketing of = sub filter expressions.=20 >>=20 >> (Filter) or not(filter) >>=20 >> Phil >>=20 >>> On Aug 13, 2020, at 8:56 AM, Shelley > wrote: >>>=20 >>> =EF=BB=BF >>> While reviewing the SCIM 2.0 filter ABNF syntax [1], I found what = appears to be a couple of issues that I wanted to confirm before = submitting errata. >>>=20 >>> Regarding the "not" filters: >>> FILTER =3D attrExp / logExp / valuePath / *1"not" "(" FILTER = ")" >>>=20 >>> valFilter =3D attrExp / logExp / *1"not" "(" valFilter ")" >>> Specifically, if I'm not mistaken: >>> there should be a space between "not" and "(" >>> alternatively, the following example [2] should not include a space: >>> not (emails co "example.com " or emails.value = co "example.org ") >>> the use of "*1" is not correct >>> this effectively makes the entire rule optional >>> As such, I think the above filters should be re-written as: >>>=20 >>> FILTER =3D attrExp / logExp / valuePath / "not" [SP] "(" = FILTER ")" >>>=20 >>> valFilter =3D attrExp / logExp / "not" [SP] "(" valFilter ")" >>>=20 >>> In case any SCIM clients/providers are relying on the existing ABNF = which does not define the space, the above syntax makes the space = optional. >>>=20 >>> Please confirm whether I've misinterpreted anything, otherwise, I = will likely report this as errata. >>>=20 >>> [1] https://tools.ietf.org/html/rfc7644#page-21 = >>> [2] https://tools.ietf.org/html/rfc7644#page-23 = _____________________________= __________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim = >=20 --Apple-Mail=_2472C4AF-2648-4507-B14B-705EFACC9909 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Shelley

Good catch. I would put in an errata for the filter = ABNF.

Phillip Hunt



On Aug 19, 2020, at 7:47 AM, Shelley <randomshelley@gmail.com> wrote:

There also seems to be a slight discrepancy between the = allowed characters in an attribute name between the SCIM Core Schema = Specification [1] and the SCIM Protocol Specification [2].

Specifically, the Core Schema ABNF seems to = allow "$" characters:

   ATTRNAME   = =3D ALPHA *(nameChar)
   nameChar   =3D "$" = / "-" / "_" / DIGIT / ALPHA

whereas = the SCIM filter ABNF does not seem to allow this character in attribute = names:

   ATTRNAME  =3D ALPHA *(nameChar)
   nameChar  =3D "-" / "_" / DIGIT / = ALPHA

Was there any reasoning behind = this discrepancy?

(In addition, if I'm not = mistaken, the "$ref" attribute in the core schema [3] seems to violate = the ABNF since it does not start with an ALPHA character. Please let me = know if I'm misunderstanding something.)

[1] = https://tools.ietf.org/html/rfc7643#section-2.1
[2] https://tools.ietf.org/html/rfc7644#page-21
[3] https://tools.ietf.org/html/rfc7643#page-12

On Thu, Aug 13, 2020 at 2:14 PM Shelley <randomshelley@gmail.com> wrote:
If adding the optional space to the ABNF is not feasible, = then perhaps the non-normative example in Figure 2 that includes the = space should be updated to remove it? This example [1] is not compliant = with the ABNF syntax:
not (emails = co "example.com" or emails.value co "example.org")

Also, is there somewhere that changes like this are being tracked for a = future SCIM spec?

Thanks for the discussion and clarification regardless=20

[1] https://tools.ietf.org/html/rfc7644#page-23

On Thu, Aug 13, 2020 at 1:02 PM Phil Hunt <phil.hunt@independentid.com> wrote:
Shelley,

I agree, the ABNF you = propose may have been a better way to express =E2=80=9Cnot=E2=80=9D = filters. AFAIK, the iETF does not allow us to make this kind of RFC = update as technically it is a normative change. 

IMO this would be a good = item to address as a clarification item in a possible future SCIM 2.1 or = 3 draft. 

Phillip Hunt
phil.hunt@independentid.com



On Aug 13, 2020, at 10:12 AM, Shelley <randomshelley@gmail.com> wrote:

OK, = thanks for the clarification. I think I better understand the intent = behind the "*1" now; this also allows for optional parentheses around = any filter expression. I presume the space should still be allowed = between the "not" and open parenthesis "(", though? The following = updated syntax includes an optional space following the "not", and also = includes the recommended parentheses grouping [1] for clarification:

     FILTER    =3D attrExp / logExp = / valuePath / ( ["not" *1SP] "(" FILTER ")" )

     valFilter =3D attrExp / logExp / ( ["not" = *1SP] "(" valFilter ")" )

[1] https://tools.ietf.org/html/rfc5234#section-3.5


On Thu, Aug = 13, 2020 at 11:27 AM Phillip Hunt <phil.hunt@independentid.com> wrote:
Shelly
The =E2=80=9Cnot=E2=80=9D= is itself optional to allow bracketing of sub filter = expressions. 

(Filter) or not(filter)

Phil

On Aug 13, 2020, at 8:56 = AM, Shelley <randomshelley@gmail.com> wrote:

=EF=BB=BF
While reviewing the SCIM 2.0 filter ABNF = syntax [1], I found what appears to be a couple of issues that I wanted = to confirm before submitting errata.

Regarding the "not" = filters:
     FILTER    =3D attrExp / logExp / valuePath / =
*1"not" "(" FILTER ")"

     valFilter =3D attrExp / logExp / *1"not" "(" valFilter ")"
Specifically, if I'm not mistaken:
  • there should be a space between = "not" and "("
    • alternatively, the = following example [2] should not include a space:
      not (emails = co "example.com" or emails.value co "example.org")
  • the use of = "*1" is not correct
    • this effectively = makes the entire rule optional
As such, I think the above filters should be re-written = as:

     FILTER =    =3D attrExp / logExp / valuePath / "not" [SP] "(" FILTER = ")"

     valFilter =3D = attrExp / logExp / "not" [SP] "(" valFilter ")"

In case any = SCIM clients/providers are relying on the existing ABNF which does not = define the space, the above syntax makes the space = optional.

Please confirm whether I've misinterpreted anything, = otherwise, I will likely report this as errata.

[1] https://tools.ietf.org/html/rfc7644#page-21
[2] https://tools.ietf.org/html/rfc7644#page-23
_______________________________________________scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


= --Apple-Mail=_2472C4AF-2648-4507-B14B-705EFACC9909--