Subject: [scim] Filter ABNF Clarifications

From: Shelley <[email-masked]>
Date: Thu, 13 Aug 2020 10:56:31 -0500

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

---

From: Phillip Hunt <[email-masked]>
Date: Thu, 13 Aug 2020 09:27:22 -0700

Shelly

The “not” is itself optional to allow bracketing of sub filter expressions. 

(Filter) or not(filter)

Phil

> On Aug 13, 2020, at 8:56 AM, Shelley <[email-masked]> wrote:
> 
> 
> 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.
> 
> there should be a space between "not" and "("
> alternatively, the following example [2] should not include a space:
> the use of "*1" is not correct
> this effectively makes the entire rule optional
> 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.
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Shelley <[email-masked]>
Date: Thu, 13 Aug 2020 12:12:07 -0500

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    = attrExp / logExp / valuePath / ( ["not" *1SP] "(" FILTER
")" )

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

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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 13 Aug 2020 11:02:30 -0700

Shelley,

I agree, the ABNF you propose may have been a better way to express “not” 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
[email-masked]

> On Aug 13, 2020, at 10:12 AM, Shelley <[email-masked]> 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    = attrExp / logExp / valuePath / ( ["not" *1SP] "(" FILTER ")" )
> 
> [1] https://tools.ietf.org/html/rfc5234#section-3.5 <https://tools.ietf.org/html/rfc5234#section-3.5>
> 
> 
> On Thu, Aug 13, 2020 at 11:27 AM Phillip Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> Shelly
> 
>> On Aug 13, 2020, at 8:56 AM, Shelley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> not (emails co "example.com <http://example.com/>" or emails.value co "example.org <http://example.org/>")
>> [1] https://tools.ietf.org/html/rfc7644#page-21 <https://tools.ietf.org/html/rfc7644#page-21>
>> [2] https://tools.ietf.org/html/rfc7644#page-23 <https://tools.ietf.org/html/rfc7644#page-23>_______________________________________________
>> scim mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>

---

From: Shelley <[email-masked]>
Date: Thu, 13 Aug 2020 14:14:12 -0500

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 <[email-masked]>
wrote:

> Shelley,
>
> I agree, the ABNF you propose may have been a better way to express “not”
> filters. AFAIK, the iETF does not allow us to make this kind of RFC update
> as technically it is a normative change.
>

---

From: Shelley <[email-masked]>
Date: Wed, 19 Aug 2020 09:47:27 -0500

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   = ALPHA *(nameChar)
   nameChar   = "$" / "-" / "_" / DIGIT / ALPHA

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

   ATTRNAME  = ALPHA *(nameChar)
   nameChar  = "-" / "_" / 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 <[email-masked]> wrote:

>> On Thu, Aug 13, 2020 at 11:27 AM Phillip Hunt <
>> [email-masked]> wrote:
>>
>>> Shelly
>>>
>>> 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.
>>>
>>> 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.
>>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 19 Aug 2020 10:20:47 -0700

Shelley

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

Phillip Hunt

> On Aug 19, 2020, at 7:47 AM, Shelley <[email-masked]> 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].
> 
> whereas the SCIM filter ABNF does not seem to allow this character in attribute names:
> 
> (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 <https://tools.ietf.org/html/rfc7643#section-2.1>
> [2] https://tools.ietf.org/html/rfc7644#page-21 <https://tools.ietf.org/html/rfc7644#page-21>
> [3] https://tools.ietf.org/html/rfc7643#page-12 <https://tools.ietf.org/html/rfc7643#page-12>
> On Thu, Aug 13, 2020 at 2:14 PM Shelley <[email-masked] <mailto:[email-masked]>> 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:
> Also, is there somewhere that changes like this are being tracked for a future SCIM spec?
> 
> [1] https://tools.ietf.org/html/rfc7644#page-23 <https://tools.ietf.org/html/rfc7644#page-23>
> On Thu, Aug 13, 2020 at 1:02 PM Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> Shelley,
> 
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
>> On Aug 13, 2020, at 10:12 AM, Shelley <[email-masked] <mailto:[email-masked]>> wrote:
>>