Re: [scim] Filter ABNF Clarifications

[Shelley <[e-mail]>]

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 <[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" 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 <[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]
>>
>>
>>
>> On Aug 13, 2020, at 10:12 AM, Shelley <[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
>>
>>
>> On Thu, Aug 13, 2020 at 11:27 AM Phillip Hunt <
>> [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]> 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" 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
>>> _______________________________________________
>>> scim mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/scim
>>>
>>>
>>