Re: [scim] [Technical Errata Reported] RFC7644 (4670)

Phil Hunt <phil.hunt@oracle.com> Mon, 18 April 2016 17:48 UTC

Return-Path: <phil.hunt@oracle.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 85D0512E3F1 for <scim@ietfa.amsl.com>; Mon, 18 Apr 2016 10:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.216
X-Spam-Level:
X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 YvOdgX2wcKzP for <scim@ietfa.amsl.com>; Mon, 18 Apr 2016 10:48:44 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 0C77012D6D7 for <scim@ietf.org>; Mon, 18 Apr 2016 10:48:43 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u3IHmcGU011203 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Apr 2016 17:48:38 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u3IHmbNB024494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Apr 2016 17:48:37 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u3IHmWj8016627; Mon, 18 Apr 2016 17:48:34 GMT
Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 18 Apr 2016 10:48:32 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_E1D0CF06-C692-4667-AD11-1EB2E8D82A18"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <C6ADAAC1-659A-4240-9289-43D0332468BF@sunet.se>
Date: Mon, 18 Apr 2016 10:48:29 -0700
Message-Id: <64CA26CD-F896-43A1-ABA7-9D094B9CD4BE@oracle.com>
References: <20160415202027.AC0E918000B@rfc-editor.org> <C6ADAAC1-659A-4240-9289-43D0332468BF@sunet.se>
To: Leif Johansson <leifj@sunet.se>
X-Mailer: Apple Mail (2.3124)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <http://mailarchive.ietf.org/arch/msg/scim/bmMGn8_SqQpR7dAEi6T3oybMXuQ>
X-Mailman-Approved-At: Mon, 18 Apr 2016 10:54:11 -0700
Cc: "ben@nostrum.com" <ben@nostrum.com>, "aamelnikov@fastmail.fm" <aamelnikov@fastmail.fm>, "morteza.ansari@cisco.com" <morteza.ansari@cisco.com>, "alissa@cooperw.in" <alissa@cooperw.in>, "zmeeagain@gmail.com" <zmeeagain@gmail.com>, "scim@ietf.org" <scim@ietf.org>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "erik.wahlstrom@nexusgroup.com" <erik.wahlstrom@nexusgroup.com>, Morteza Ansari <moransar@cisco.com>, Chuck Mortimore <cmortimore@salesforce.com>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [scim] [Technical Errata Reported] RFC7644 (4670)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 18 Apr 2016 17:48:46 -0000

Just confirming that the text was changed between drafts 17-19 during the IESG review process based on feedback that we had a normative reference to wikipedia which wasn’t valid.

The order of the list really depends on how you interpret the overall sentence structure. At present I do find it somewhat awkward.

For example, if you are taking a parser perspective, you are breaking down the filter based on the order specified.  However, if you are saying which rule is more important than the other, than the proposed text is correct.

Would appreciate other comments.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>





> On Apr 17, 2016, at 1:06 PM, Leif Johansson <leifj@sunet.se> wrote:
> 
> Somebody want to venture an opinion on this?
> 
> Skickat från min iPhone
> 
>> 15 apr. 2016 kl. 22:21 skrev RFC Errata System <rfc-editor@rfc-editor.org>:
>> 
>> The following errata report has been submitted for RFC7644,
>> "System for Cross-domain Identity Management: Protocol".
>> 
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=7644&eid=4670
>> 
>> --------------------------------------
>> Type: Technical
>> Reported by: Vassilis Michalitsis <zmeeagain@gmail.com>
>> 
>> Section: 3.4.2.2
>> 
>> Original Text
>> -------------
>> Filters MUST be evaluated using the following order of operations, in
>>  order of precedence:
>> 
>>  1.  Grouping operators
>> 
>>  2.  Logical operators - where "not" takes precedence over "and",
>>      which takes precedence over "or"
>> 
>>  3.  Attribute operators
>> 
>> Corrected Text
>> --------------
>> Filters MUST be evaluated using the following order of operations, in
>>  order of precedence:
>> 
>>  1.  Grouping operators
>> 
>>  2.  Attribute operators
>> 
>>  3.  Logical operators - where "not" takes precedence over "and",
>>      which takes precedence over "or"
>> 
>> Notes
>> -----
>> It seems that the precedence of logical and attribute precedence is reversed? The filter filter=title sw "M" and userType eq "Employee" is meant to be interpreted as filter=(title sw "M") and (userType eq "Employee"). 
>> This is also the "expected" behaviour consistent with most other languages - with the notable exception of unary "or" which in SCIM is disambiguated as it can only apply to a parenthesized filter expression.
>> 
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary. 
>> 
>> --------------------------------------
>> RFC7644 (draft-ietf-scim-api-19)
>> --------------------------------------
>> Title               : System for Cross-domain Identity Management: Protocol
>> Publication Date    : September 2015
>> Author(s)           : P. Hunt, Ed., K. Grizzle, M. Ansari, E. Wahlstroem, C. Mortimore
>> Category            : PROPOSED STANDARD
>> Source              : System for Cross-domain Identity Management
>> Area                : Applications and Real-Time
>> Stream              : IETF
>> Verifying Party     : IESG
>>