Re: [scim] Filter ABNF Clarifications

[Phil Hunt <[e-mail]>]

Shelley

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

Phillip Hunt
[e-mail]



> On Aug 19, 2020, at 7:47 AM, Shelley <[e-mail]> 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   = 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 <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 <[e-mail] <mailto:[e-mail]>> 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 <http://example.com/>" or emails.value co "example.org <http://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 <https://tools.ietf.org/html/rfc7644#page-23>
> On Thu, Aug 13, 2020 at 1:02 PM Phil Hunt <[e-mail] <mailto:[e-mail]>> 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. 
> 
> 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
> [e-mail] <mailto:[e-mail]>
> 
> 
> 
>> On Aug 13, 2020, at 10:12 AM, Shelley <[e-mail] <mailto:[e-mail]>> 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 ")" )
>> 
>>      valFilter = attrExp / logExp / ( ["not" *1SP] "(" valFilter ")" )
>> 
>> [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 <[e-mail] <mailto:[e-mail]>> wrote:
>> 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 <[e-mail] <mailto:[e-mail]>> 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.
>>> 
>>> 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 <http://example.com/>" or emails.value co "example.org <http://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 <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
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>
>