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

[Phillip Hunt <[e-mail]>]

Hold for Document Update seems best. 

Phil

> On Sep 12, 2022, at 8:14 AM, Murray S. Kucherawy <[e-mail]> wrote:
> 
> 
> These are the possible answers:
> 
> https://www.rfc-editor.org/errata-definitions/
> 
> I agree that we can't use "Verified" since the text of the RFC represents the consensus at the time it was published.  We would normally verify an erratum if what the community meant to publish and what actually got published were not the same thing.
> 
> Perhaps "Hold For Document Update" is the appropriate response?
> 
> -MSK, ART AD
> 
>> On Fri, Sep 9, 2022 at 12:33 PM Phillip Hunt <[e-mail]> wrote:
>> 
>> As one of the RFC authors ([e-mail]), I think this probably has to be rejected because it introduces a normative change.
>> 
>> 
>> Reason: The specified way to handle multi-valued attribute is to use a valuePath expression using “value” as the sub-attribute (even when the attribute is not complex) per: 
>>>  o  If the target location is a multi-valued attribute and a complex
>>>       filter is specified comparing a "value", the values matched by the
>>>       filter are removed.  If no other values remain after removal of
>>>       the selected values, the multi-valued attribute SHALL be
>>>       considered unassigned.
>> 
>> I agree the errata suggests an easier way that is likely supported in many implementations but still represents a normative change. There is also a side-effect if introducing new conditional logic on single valued attrubtes that were not originally intended.
>> 
>> As to the example cited in the errata the correct way to specify per the paragraph above is:
>> {
>>  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
>>  "Operations":[{
>>    "op":"remove",
>>    "path":”schemas[value eq \"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User\]""
>>  }]
>> }
>> 
>> With that said, I find myself sayinig why not?  The working group may wish to take this on in any SCIM 2.x discussions.
>> 
>> Phillip Hunt
>> @independentid
>> [e-mail]
>> 
>> 
>> 
>> 
>>> On Sep 8, 2022, at 3:33 AM, RFC Errata System <[e-mail]> wrote:
>>> 
>>> The following errata report has been submitted for RFC7644,
>>> "System for Cross-domain Identity Management: Protocol".
>>> 
>>> --------------------------------------
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid7122
>>> 
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Egil Hansen <[e-mail]>
>>> 
>>> Section: 3.5.2
>>> 
>>> Original Text
>>> -------------
>>>   The "path" attribute is described by the following ABNF syntax rule:
>>> 
>>>                   PATH = attrPath / valuePath [subAttr]
>>> 
>>>                      Figure 7: SCIM PATCH PATH Rule
>>> 
>>>   The ABNF rules "attrPath", "valuePath", and "subAttr" are defined in
>>>   Section 3.4.2.2.  The "valuePath" rule allows specific values of a
>>>   complex multi-valued attribute to be selected.
>>> 
>>> Corrected Text
>>> --------------
>>>   The "path" attribute is described by the following ABNF syntax rule:
>>> 
>>>                   PATH = attrPath / valuePath [subAttr] / attrExp
>>> 
>>>                      Figure 7: SCIM PATCH PATH Rule
>>> 
>>>   The ABNF rules "attrPath", "valuePath", "subAttr", and "attrExp" are 
>>>   defined in Section 3.4.2.2. The "valuePath" rule allows specific 
>>>   values of a complex multi-valued attribute to be selected.
>>> 
>>> Notes
>>> -----
>>> In section 3.5.2.2. (Remove Operation), states:
>>> 
>>> "If the target location is a multi-valued attribute and a complex
>>> filter is specified comparing a "value", the values matched by the
>>> filter are removed.  If no other values remain after removal of
>>> the selected values, the multi-valued attribute SHALL be
>>> considered unassigned."
>>> 
>>> This means it should be possible to create a filter that selects a value from a multi-valued attribute that is not complex. Writing such a filter seems impossible without having "attrExp" as a possible legal PATH.
>>> 
>>> In section 3.4.2.2.  (Filtering) there is an example that shows how such a filter could look for a multi-valued attribute, i.e.:
>>> 
>>> filter=
>>> schemas eq "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
>>> 
>>> This would also work for a path filter, e.g.:
>>> 
>>> {
>>>  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
>>>  "Operations":[{
>>>    "op":"remove",
>>>    "path":"schemas eq \"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User\""
>>>  }]
>>> }
>>> 
>>> 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  
>>> 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
>>