— Resending with author team cc’ed— > Begin forwarded message: > > From: "IANA General Enquiries via RT" <[email protected]> > Subject: [IANA #1451825] AutoReply: [IANA] AUTH48: RFC-to-be 9967 > <draft-ietf-scim-events-16> for your review > Date: May 8, 2026 at 11:15:27 AM PDT > To: [email protected] > Reply-To: [email protected] > > To whom it may concern: > > This is an automatically generated message to notify you that we have > received your request, and it has been recorded in our ticketing > system with a reference number of 1451825. > > There is no need to reply to this message right now. IANA staff will review > your message and reply to your inquiry within three (3) business days. > > If this message is in reply to a previously submitted ticket, it is > possible that the previous ticket has been marked as closed. As we > review this ticket, we will also review previous correspondence and > take appropriate action. > > To expedite processing, and ensure our staff can view the full history > of this request, please make sure you include the following exact text in > the subject line of all future correspondence on this issue: > > [IANA #1451825] > > You can also simply reply to this message, as this tag is already in > the subject line. > > Thank you, > > IANA Services > [email protected] > PTI > > Please note: By submitting my personal data, I agree that my personal data > will be processed in accordance with the Privacy Policy > <https://www.icann.org/privacy/policy>. > > ------------------------------------------------------------------------- > Dear IANA, > > Please update the "SCIM Event URIs” registry > <https://www.iana.org/assignments/scim/> to match the updated document at > <https://www.rfc-editor.org/authors/rfc9967-diff.html>. > > 1) First column header: > > Old: > Schema URI > > New: > Event URI > > 2) Description: > > Old: > urn:ietf:params:scim:event:feed:remove | Remove resource From Feed > Event > > New: > urn:ietf:params:scim:event:feed:remove | Remove resource from Feed > Event > > > Thanks in advance! > > Karen Moore > RFC Production Center > > >> Begin forwarded message: >> >> From: Karen Moore <[email protected]> >> Subject: Re: AUTH48: RFC-to-be 9967 <draft-ietf-scim-events-16> for your >> review >> Date: May 8, 2026 at 11:00:26 AM PDT >> To: "Nancy Cam-Winget (ncamwing)" <[email protected]>, Jen Schreiber >> <[email protected]>, Mike Kiser <[email protected]>, "[email protected]" >> <[email protected]>, Phillip Hunt <[email protected]> >> Cc: "[email protected]" <[email protected]>, >> "[email protected]" <[email protected]>, "[email protected]" >> <[email protected]>, "[email protected]" <[email protected]>, >> "[email protected]" <[email protected]>, "[email protected]" >> <[email protected]> >> >> Hi Nancy and Jen, >> >> Thank you for your replies. We have noted Nancy’s approval on the AUTH48 >> status page at <https://www.rfc-editor.org/auth48/rfc9967>. >> >> We will now ask IANA to update their registry to match the edited document. >> We will inform you when the update is complete. >> >> Best regards, >> >> Karen Moore >> RFC Production Center >> >> >>> On May 7, 2026, at 5:16 PM, Nancy Cam-Winget (ncamwing) >>> <[email protected]> wrote: >>> >>> >>> Apologies for the delays, but I approve of the document….thanks. - Nancy >>> From: Karen Moore <[email protected]> >>> Date: Thursday, May 7, 2026 at 1:45 PM >>> To: [email protected] <[email protected]>; Mike Kiser >>> <[email protected]>; Jen Schreiber <[email protected]>; Phillip >>> Hunt <[email protected]>; Nancy Cam-Winget (ncamwing) >>> <[email protected]> >>> Cc: [email protected] <[email protected]>; [email protected] >>> <[email protected]>; [email protected] <[email protected]>; >>> [email protected] <[email protected]>; [email protected] >>> <[email protected]>; [email protected] >>> <[email protected]> >>> Subject: Re: [AD] AUTH48: RFC-to-be 9967 <draft-ietf-scim-events-16> for >>> your review >>> >>> Hi Deb, Mike, and *Jen, >>> >>> Thank you for your replies. We have noted approval of the document for each >>> of you at <https://www.rfc-editor.org/auth48/rfc9967>. >>> >>> We now await approval of the document from Nancy. Once received, we will >>> ask IANA to update their registry to match the edited document prior to >>> moving forward with publication. >>> >>> *Jen, we updated your email address. For your affiliation, would you like >>> to remove or replace “Workday”? >>> >>> >>> —Files (please refresh)— >>> >>> Updated XML file: >>> https://www.rfc-editor.org/authors/rfc9967.xml >>> >>> Updated output files: >>> https://www.rfc-editor.org/authors/rfc9967.txt >>> https://www.rfc-editor.org/authors/rfc9967.pdf >>> https://www.rfc-editor.org/authors/rfc9967.html >>> >>> Diff files showing all changes made during AUTH48: >>> https://www.rfc-editor.org/authors/rfc9967-auth48diff.html >>> https://www.rfc-editor.org/authors/rfc9967-auth48rfcdiff.html (side by side) >>> >>> Diff files showing only the changes made in the last edit round: >>> https://www.rfc-editor.org/authors/rfc9967-lastdiff.html >>> https://www.rfc-editor.org/authors/rfc9967-lastrfcdiff.html (side by side) >>> >>> Diff files showing all changes: >>> https://www.rfc-editor.org/authors/rfc9967-diff.html >>> https://www.rfc-editor.org/authors/rfc9967-rfcdiff.html (side by side) >>> >>> Best regards, >>> >>> Karen Moore >>> RFC Production Center >>> >>> >>>> On May 7, 2026, at 3:37 AM, Deb Cooley <[email protected]> wrote: >>>> >>>> I approve. >>>> >>>> Deb Cooley >>> >>>> On May 6, 2026, at 6:14 PM, Mike Kiser <[email protected]> wrote: >>>> >>>> I approve of the document as well. >>>> >>>> -Mike >>>> >>>> Get Outlook for iOSFrom: Jen Schreiber <[email protected]> >>>> Sent: Wednesday, May 6, 2026 7:08:38 PM >>>> To: Karen Moore <[email protected]> >>>> Cc: [email protected] <[email protected]>; Phillip Hunt >>>> <[email protected]>; Mike Kiser <[email protected]>; >>>> Nancy Cam-Winget <[email protected]>; [email protected] <[email protected]>; >>>> [email protected] <[email protected]>; [email protected] >>>> <[email protected]>; [email protected] <[email protected]>; >>>> [email protected] <[email protected]>; [email protected] >>>> <[email protected]> >>>> Subject: Re: [AD] Re: AUTH48: RFC-to-be 9967 <draft-ietf-scim-events-16> >>>> for your review >>>> Hi Karen - >>>> >>>> I have read through the latest changes - I approve. >>>> >>>> Can you update my email address on the document to [email protected]? >>>> >>>> Thank you, >>>> Jen >>>> >>>> On Wed, May 6, 2026 at 5:04 PM Karen Moore <[email protected]> >>>> wrote: >>>> Hi Phil and *Deb (AD), >>>> >>>> Thanks for your reply. Phil, we believe you have provided your approval of >>>> the document in its current form, so we have marked your approval at >>>> <https://www.rfc-editor.org/auth48/rfc9967>. We now await approval of the >>>> document from Jen, Mike, and Nancy. >>>> >>>> *Deb, please review the update in Section 5 and let us know if you >>>> approve. The update is highlighted below and can be viewed at >>>> <https://www.rfc-editor.org/authors/rfc9967-auth48diff.html>. >>>> >>>> Original: >>>> Providing the exact date of each membership change is not critical >>>> but instead that the information content remains intact. >>>> >>>> Current: >>>> If providing the exact date of each membership change is not critical, >>>> consider using a PATCH to aggregate multiple membership changes into a >>>> single event. >>>> >>>> >>>> —Files (please refresh)— >>>> >>>> Updated XML file: >>>> https://www.rfc-editor.org/authors/rfc9967.xml >>>> >>>> Updated output files: >>>> https://www.rfc-editor.org/authors/rfc9967.txt >>>> https://www.rfc-editor.org/authors/rfc9967.pdf >>>> https://www.rfc-editor.org/authors/rfc9967.html >>>> >>>> Diff files showing all changes made during AUTH48: >>>> https://www.rfc-editor.org/authors/rfc9967-auth48diff.html >>>> https://www.rfc-editor.org/authors/rfc9967-auth48rfcdiff.html (side by >>>> side) >>>> >>>> Diff files showing only the changes made in the last edit round: >>>> https://www.rfc-editor.org/authors/rfc9967-lastdiff.html >>>> https://www.rfc-editor.org/authors/rfc9967-lastrfcdiff.html (side by side) >>>> >>>> Diff files showing all changes: >>>> https://www.rfc-editor.org/authors/rfc9967-diff.html >>>> https://www.rfc-editor.org/authors/rfc9967-rfcdiff.html (side by side) >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://www.rfc-editor.org/auth48/rfc9967 >>>> >>>> Best regards, >>>> >>>> Karen Moore >>>> RFC Production Center >>>> >>>>> On May 6, 2026, at 2:34 PM, Phillip Hunt <[email protected]> >>>>> wrote: >>>>> >>>>> Looks good to me. Thanks! >>>>> >>>>> Phil >>>>> [email protected] >>>>> >>>>> >>>>>> On May 6, 2026, at 2:29 PM, Karen Moore <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hi Phil and Mike, >>>>>> >>>>>> Thank you for your replies. Once we have Jennifer’s updated email >>>>>> address, we will point her to the email list archive for this document >>>>>> so she can review the correspondence and updates that have taken place >>>>>> to date. >>>>>> >>>>>> We have updated our files to reflect the changes to Figure 21. We have >>>>>> also updated the terminology as follows. Please review the updated files >>>>>> and let us know if any further updates are needed for consistency. >>>>>> >>>>>> Currently: >>>>>> Asynchronous Request Completion Event >>>>>> Asynchronous Event completion events >>>>>> [Note: This is the only instance of this form (Section 2.5.1.2.). >>>>>> Should this be "asynchronous completion events”?] >>>>>> Asynchronous Response Event Token >>>>>> Asynchronous Response Event >>>>>> >>>>>> asynchronous completion events >>>>>> asynchronous request completion >>>>>> asynchronous response >>>>>> asynchronous SCIM request capability >>>>>> asynchronous SCIM request >>>>>> >>>>>> SCIM Event >>>>>> SCIM Event Token >>>>>> Event Receiver >>>>>> Event Publisher >>>>>> PATCH Event >>>>>> SET Event >>>>>> Security Event >>>>>> >>>>>> Event Feed -> event feed (per RFC 8417 and other RFCs) >>>>>> Event Payload -> event payload (per RFC 8417) >>>>>> SCIM Client -> SCIM client (per RFCs 7643 and 7644) >>>>>> SCIM Complex attribute -> SCIM complex attribute (per RFC 7644) >>>>>> SCIM Protocol -> SCIM protocol (per RFC 7644) >>>>>> SCIM Resource -> SCIM resource (per RFCs 7643 and 7644) >>>>>> SCIM Response -> SCIM response (per RFC 7644) >>>>>> SCIM Schema -> SCIM schema (per RFC 7643) >>>>>> SCIM Service Provider -> SCIM service provider (per RFCs 7643, 7644, and >>>>>> 9865) >>>>>> >>>>>> —Files (please refresh)— >>>>>> >>>>>> Please contact us with any further updates or with your approval of the >>>>>> document in its current form. We will await approvals from each author >>>>>> prior to moving forward in the publication process. >>>>>> >>>>>> Updated XML file: >>>>>> https://www.rfc-editor.org/authors/rfc9967.xml >>>>>> >>>>>> Updated output files: >>>>>> https://www.rfc-editor.org/authors/rfc9967.txt >>>>>> https://www.rfc-editor.org/authors/rfc9967.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9967.html >>>>>> >>>>>> Diff files showing all changes made during AUTH48: >>>>>> https://www.rfc-editor.org/authors/rfc9967-auth48diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9967-auth48rfcdiff.html (side by >>>>>> side) >>>>>> >>>>>> Diff files showing only the changes made in the last edit round: >>>>>> https://www.rfc-editor.org/authors/rfc9967-lastdiff.html >>>>>> https://www.rfc-editor.org/authors/rfc9967-lastrfcdiff.html (side by >>>>>> side) >>>>>> >>>>>> Diff files showing all changes: >>>>>> https://www.rfc-editor.org/authors/rfc9967-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9967-rfcdiff.html (side by side) >>>>>> >>>>>> For the AUTH48 status of this document, please see: >>>>>> https://www.rfc-editor.org/auth48/rfc9967 >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Karen Moore >>>>>> RFC Production Center >>>>>> >>>>>>> On May 6, 2026, at 6:16 AM, Mike Kiser <[email protected]> wrote: >>>>>>> >>>>>>> I've contacted her this morning and will provide the update when she >>>>>>> gives the preferred email that she wants on the spec. (she's changed >>>>>>> companies since the spec was originally drafted.) >>>>>>> >>>>>>> -MikeFrom: Karen Moore <[email protected]> >>>>>>> Sent: Tuesday, May 5, 2026 20:05 >>>>>>> To: Phillip Hunt <[email protected]> >>>>>>> Cc: [email protected] >>>>>>> <[email protected]>; Mike Kiser >>>>>>> <[email protected]>; Nancy Cam-Winget <[email protected]>; >>>>>>> [email protected]<[email protected]>; >>>>>>> [email protected] <[email protected]>; >>>>>>> [email protected] <[email protected]>; [email protected] >>>>>>> <[email protected]>; [email protected] >>>>>>> <[email protected]>;[email protected]<[email protected]>; >>>>>>> [email protected] <[email protected]> >>>>>>> Subject: Re: questions - Re: AUTH48: RFC-to-be 9967 >>>>>>> <draft-ietf-scim-events-16> for your review >>>>>>> Hi Phil, >>>>>>> >>>>>>> Thank you for your reply - we will get back to you shortly with updated >>>>>>> files to review. >>>>>>> >>>>>>> Do you or one of your coauthors have a current email address for >>>>>>> Jennifer? >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Karen Moore >>>>>>> RFC Production Center >>>>>>> >>>>>>>> On May 5, 2026, at 4:30 PM, Phillip Hunt <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> We also might want to change Jennifer’s email as it is bouncing. >>>>>>>> >>>>>>>> Phil >>>>>>>> [email protected] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On May 5, 2026, at 1:49 PM, Karen Moore <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Phil, >>>>>>>>> >>>>>>>>> Thank you for your reply. We have updated our files accordingly. Note >>>>>>>>> that we have some additional questions. >>>>>>>>> >>>>>>>>> 1) Please clarify if the column header in Table 1 (Section 7.4) >>>>>>>>> should be "Event URI”, "Schema URI”, or other. If you feel that >>>>>>>>> further explanation is needed, you can add text to the Definitions >>>>>>>>> section as you suggest or a note under Table 1. >>>>>>>>> >>>>>>>>>> <!-- [rfced] In Section 7.4, the header of the first column in >>>>>>>>>> Table 1 is "Event URI", but it is "Schema URI" in the >>>>>>>>>> "SCIM Event URIs" registry >>>>>>>>>> <https://urldefense.com/v3/__https://www.iana.org/assignments/scim/__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11P35nQcQ$>. >>>>>>>>>> Do you prefer to use "Event URI" or "Schema URI"? Note that we >>>>>>>>>> will communicate any changes to the registry to IANA. >>>>>>>>>> >>>>>>>>>> <PH> These are actually different uses. EventURIs are used in JWT not >>>>>>>>>> in SCIM protocol itself. SCIM “Schemas” do appear in some SCIM Events >>>>>>>>>> (e.g. urn:ietf:params:scim:event:prov:create:full has a “data” >>>>>>>>>> element >>>>>>>>>> that contains schemas. (See Figure 4) >>>>>>>>>> >>>>>>>>>> Not sure if we need better explanation somewhere such as definitions? >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> 2) We have not made any updates yet to the case of the terminology in >>>>>>>>> question. We suggest going with lowercase to match RFCs 7643 and >>>>>>>>> 7644; however, this is author preference. Please discuss with your >>>>>>>>> coauthors and confirm if you would like to go with uppercase or >>>>>>>>> lowercase and we will make the updates. >>>>>>>>> >>>>>>>>> 3) Thank you for providing the updated SVG figures. Regarding Figure >>>>>>>>> 21, we note that the SVG version in the html file contains a loop but >>>>>>>>> the ascii-art version in the txt file does not. Is this variance >>>>>>>>> okay, or should it be described in the running text or noted under >>>>>>>>> the figure? >>>>>>>>> >>>>>>>>> Also, in the box in the upper right corner, should "Co-op Action >>>>>>>>> Endpoint” be “Coord. Action Endpoint”? >>>>>>>>> >>>>>>>>> —Files— >>>>>>>>> >>>>>>>>> Note that it may be necessary for you to refresh your browser to view >>>>>>>>> the most recent version. Please review the document carefully to >>>>>>>>> ensure satisfaction as we do not make changes once it has been >>>>>>>>> published as an RFC. >>>>>>>>> >>>>>>>>> Please contact us with any further updates or with your approval of >>>>>>>>> the document in its current form. We will await approvals from each >>>>>>>>> author prior to moving forward in the publication process. >>>>>>>>> >>>>>>>>> Updated XML file: >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.xml__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv13xS_DYZQ$ >>>>>>>>> >>>>>>>>> Updated output files: >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.txt__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv103qvMPNA$ >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.pdf__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv138UdRaTA$ >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11HOZW8Ng$ >>>>>>>>> >>>>>>>>> Diff files showing all changes made during AUTH48: >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-auth48diff.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv133m8cO-g$ >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-auth48rfcdiff.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv13CfpbtNg$ >>>>>>>>> (side by side) >>>>>>>>> >>>>>>>>> Diff files showing all changes: >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-diff.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv13pzUjN2w$ >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-rfcdiff.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11TjA_l9w$ >>>>>>>>> (side by side) >>>>>>>>> >>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9967__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv110ODAcOg$ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Karen Moore >>>>>>>>> RFC Production Center >>>>>>>>> >>>>>>>>> >>>>>>>>>> On May 3, 2026, at 1:25 PM, Phillip Hunt >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thank you very much for the feedback! >>>>>>>>>> >>>>>>>>>> My answers are included below. As I agree with only some subtle >>>>>>>>>> changes, I will let you update the rfc editor version rather than >>>>>>>>>> producing draft 17. >>>>>>>>>> >>>>>>>>>> Please find attached 4 files for the 2 figures. I have attempted to >>>>>>>>>> make them align. The contents should be paste-able directly in the >>>>>>>>>> document xml >>>>>>>>>> >>>>>>>>>> Let me know if there is anything else. >>>>>>>>>> >>>>>>>>>> —> co-authors, please check as well per the instructions in the >>>>>>>>>> previous email. >>>>>>>>>> >>>>>>>>>> Phil >>>>>>>>>> [email protected] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On May 1, 2026, at 3:17 PM, [email protected] wrote: >>>>>>>>>>> >>>>>>>>>>> Authors, >>>>>>>>>>> >>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>>>>>> necessary) the following questions, which are also in the source >>>>>>>>>>> file. >>>>>>>>>>> >>>>>>>>>>> 1) <!--[rfced] Please note that the title of the document has >>>>>>>>>>> been updated as follows. Abbreviations have been expanded per >>>>>>>>>>> Section 3.6 of RFC 7322 ("RFC Style Guide"), and the short title >>>>>>>>>>> that spans the header of the PDF file has been updated as shown >>>>>>>>>>> below. Please review. >>>>>>>>>>> >>>>>>>>>>> Original (document title): >>>>>>>>>>> SCIM Profile for Security Event Tokens >>>>>>>>>>> >>>>>>>>>>> Current: >>>>>>>>>>> System for Cross-domain Identity Management (SCIM) Profile for >>>>>>>>>>> Security Event Tokens (SETs) >>>>>>>>>>> >>>>>>>>>>> ... >>>>>>>>>>> Original (short title): >>>>>>>>>>> draft-ietf-scim-events-16 >>>>>>>>>>> >>>>>>>>>>> Current: >>>>>>>>>>> SCIM Profile for SETs >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>> <PH> oik >>>>>>>>>>> >>>>>>>>>>> 2) <!--[rfced] Abstract: FYI, we added the RFC number of the SET >>>>>>>>>>> specification >>>>>>>>>>> (RFC 8417) so that the text is more specific. Please let us know if >>>>>>>>>>> you >>>>>>>>>>> prefer otherwise. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> This specification defines a set of System for Cross-domain Identity >>>>>>>>>>> Management (SCIM) Security Events using the Security Event Token >>>>>>>>>>> Specification to enable the asynchronous exchange of messages >>>>>>>>>>> between >>>>>>>>>>> SCIM Service Providers and receivers. >>>>>>>>>>> >>>>>>>>>>> Current: >>>>>>>>>>> This specification defines a set of System for Cross-domain Identity >>>>>>>>>>> Management (SCIM) Security Events using the Security Event Token >>>>>>>>>>> (SET) specification (RFC 8417) to enable the asynchronous exchange >>>>>>>>>>> of >>>>>>>>>>> messages between SCIM Service Providers and receivers. >>>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> <PH> No opinions. I thought RFC numbers not allowed in abstracts. :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3) <!--[rfced] The term "SCIM Protocol Client" does not appear in >>>>>>>>>>> RFC 7644 >>>>>>>>>>> or other RFCs, so may we update it to "SCIM client" (2 instances), >>>>>>>>>>> which >>>>>>>>>>> is used in RFC 7644? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> This specification defines the use of the HTTP Header "Prefer: >>>>>>>>>>> respond-async" [RFC7240] to allow a SCIM Protocol Client [RFC7644] >>>>>>>>>>> to >>>>>>>>>>> request an asynchronous response (see Section 2.5.1.1). >>>>>>>>>>> >>>>>>>>>>> Using the HTTP protocol, a SCIM Protocol Client issues commands... >>>>>>>>>>> >>>>>>>>>>> Perhaps: >>>>>>>>>>> This specification defines the use of the HTTP Header "Prefer: >>>>>>>>>>> respond-async" [RFC7240] to allow a SCIM client [RFC7644] to >>>>>>>>>>> request an asynchronous response (see Section 2.5.1.1). >>>>>>>>>>> >>>>>>>>>>> Using the HTTP protocol, a SCIM client issues commands... >>>>>>>>>>> —> >>>>>>>>>>> >>>>>>>>>> <PH> ok >>>>>>>>>>> >>>>>>>>>>> 4) <!-- [rfced] We note that RFC 8935 does not use the terms "SET >>>>>>>>>>> Push >>>>>>>>>>> Transfer" or "Push Transfer"; it does use "push-based SET >>>>>>>>>>> delivery". RFC 8936 does not use "SET Poll-Based Transfer" or >>>>>>>>>>> "Poll-Based Transfer"; it does use "poll-based SET delivery". Is >>>>>>>>>>> an update needed for consistency? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> In the case of SET Push Transfer [RFC8935], the Event Receiver is >>>>>>>>>>> an HTTP Service Endpoint that receives requests. In the case of SET >>>>>>>>>>> Poll-Based Transfer [RFC8936], the receiver is an HTTP client that >>>>>>>>>>> initiates HTTP request to an Event Publisher endpoint. >>>>>>>>>>> >>>>>>>>>>> Perhaps: >>>>>>>>>>> In the case of push-based SET delivery [RFC8935], the Event Receiver >>>>>>>>>>> is an HTTP Service Endpoint that receives requests. In the case of >>>>>>>>>>> poll-based SET delivery [RFC8936], the receiver is an HTTP client >>>>>>>>>>> that initiates HTTP requests to an Event Publisher endpoint. >>>>>>>>>>> --> >>>>>>>>>> <PH> ok >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 5) <!--[rfced] In Section 3.1, we replaced "SET" with "Security >>>>>>>>>>> Event >>>>>>>>>>> Token (SET)" for consistency with how the other terms are >>>>>>>>>>> displayed in the list. Please let us know of any objection. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> SET: Abbreviation for "Security Event Token" as defined in [RFC8417] >>>>>>>>>>> >>>>>>>>>>> Current: >>>>>>>>>>> Security Event Token (SET): As defined in [RFC8417]. >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>> <PH> ok >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 6) <!--[rfced] In Sections 2.1, 2.2, and 4, may we add colons to >>>>>>>>>>> the list of >>>>>>>>>>> terms/attributes that are defined, or do you prefer no colons? >>>>>>>>>>> >>>>>>>>>>> One example >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> uri >>>>>>>>>>> The SCIM relative path for the resource which usually consists of >>>>>>>>>>> the resource type endpoint plus the resource "id" ... >>>>>>>>>>> >>>>>>>>>>> Perhaps >>>>>>>>>>> uri: >>>>>>>>>>> The SCIM relative path for the resource that usually consists of >>>>>>>>>>> the resource type endpoint plus the resource "id" ... >>>>>>>>>>> --> >>>>>>>>>> <PH> no objection >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 7) <!--[rfced] Section 3.1 of [RFC7643] uses "id" rather than "Id". >>>>>>>>>>> Is an >>>>>>>>>>> update needed in this sentence for consistency? >>>>>>>>>>> >>>>>>>>>>> Current: >>>>>>>>>>> id >>>>>>>>>>> The SCIM Id attribute (defined in Section 3.1 of [RFC7643]) MAY be >>>>>>>>>>> used for backwards compatibility reasons in addition to the "uri" >>>>>>>>>>> claim. >>>>>>>>>>> >>>>>>>>>>> Perhaps: >>>>>>>>>>> id >>>>>>>>>>> The SCIM "id" attribute (defined in Section 3.1 of [RFC7643]) MAY be >>>>>>>>>>> used for backwards compatibility reasons in addition to the "uri" >>>>>>>>>>> claim. >>>>>>>>>>> --> >>>>>>>>>> <PH> ok >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8) <!-- [rfced] Section 4 of [RFC7643] uses "userName" rather than >>>>>>>>>>> "username" when referring to the attribute. Should this text >>>>>>>>>>> be updated accordingly? >>>>>>>>>>> >>>>>>>>>>> Section 2.1 >>>>>>>>>>> Current: >>>>>>>>>>> For example, attributes such as "emails" or "username" (defined in >>>>>>>>>>> Section 4 of [RFC7643]) are unique with in a SCIM Service Provider. >>>>>>>>>>> >>>>>>>>>>> Perhaps: >>>>>>>>>>> For example, attributes such as "emails" or "userName" (defined in >>>>>>>>>>> Section 4 of [RFC7643]) are unique with in a SCIM Service Provider. >>>>>>>>>>> >>>>>>>>>>> ... >>>>>>>>>>> Section 2.2 >>>>>>>>>>> Current: >>>>>>>>>>> For example: "attributes": ["username","emails","name.familyName"] >>>>>>>>>>> >>>>>>>>>>> Perhaps: >>>>>>>>>>> For example: "attributes": ["userName","emails","name.familyName"] >>>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> <PH> attributes in JWT and SCIM are case insensitive. But the case >>>>>>>>>> as was written was consistent with RFC7643 (which is userName). I >>>>>>>>>> have no objections either way. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 9) <!--[rfced] FYI, in Section 2.2 about "attributes", please >>>>>>>>>>> review: >>>>>>>>>>> - removed the extraneous '>' in '"path">'. Seems it was a typo. >>>>>>>>>>> - removed the line break after "For example:". If you prefer that >>>>>>>>>>> the example be in a sourcecode element, please let us know. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> Names of modified attributes SHOULD conform to the ABNF syntax rule >>>>>>>>>>> for "path"> (Section 3.5.2 of [RFC7644]). >>>>>>>>>>> For example: >>>>>>>>>>> "attributes": ["username","emails","name.familyName"] >>>>>>>>>>> >>>>>>>>>>> Current: >>>>>>>>>>> Names of modified attributes SHOULD conform to the ABNF syntax >>>>>>>>>>> rule for "path" (see Section 3.5.2 of [RFC7644] and [RFC5234]). >>>>>>>>>>> For example: "attributes": ["username","emails","name.familyName"]. >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> <PH> thanks. correct. >>>>>>>>>> >>>>>>>>>>> 10) <!--[rfced] Should the middle initial for Barbara Jensen III be >>>>>>>>>>> "J." >>>>>>>>>>> (with a period) in Figure 12, or is the current text correct? >>>>>>>>>>> >>>>>>>>>>> Current: >>>>>>>>>>> "formatted":"Ms. Barbara J Jensen III" >>>>>>>>>>> >>>>>>>>>>> Perhaps: >>>>>>>>>>> "formatted":"Ms. Barbara J. Jensen III" >>>>>>>>>>> — >>>>>>>>>>> >>>>>>>>>> <PH> Just an example, doesn’t matter. The example in Figure 2 of >>>>>>>>>> RFC7643 has no period. >>>>>>>>>>> >>>>>>>>>>> 11) <!--[rfced] We note that Figure 13 is the only figure without a >>>>>>>>>>> title. Would you like to add one? If so, please provide the >>>>>>>>>>> desired text. >>>>>>>>>>> —> >>>>>>>>>>> >>>>>>>>>> <PH> How about "Async SCIM Request With Prefer Header" >>>>>>>>>>> >>>>>>>>>>> 12) <!--[rfced] The following sentence does not parse. Please let >>>>>>>>>>> us know >>>>>>>>>>> how we may update for clarity. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> Providing the exact date of each membership change is not critical >>>>>>>>>>> but instead that the information content remains intact. >>>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> <PH> Proposed: >>>>>>>>>> >>>>>>>>>> If providing the exact date of each membership change is not >>>>>>>>>> critical, consider >>>>>>>>>> using a PATCH to aggregate multiple membership changes into a single >>>>>>>>>> event. >>>>>>>>>> </PH> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 13) <!-- [rfced] In Section 7.4, the header of the first column in >>>>>>>>>>> Table 1 is "Event URI", but it is "Schema URI" in the >>>>>>>>>>> "SCIM Event URIs" registry >>>>>>>>>>> <https://urldefense.com/v3/__https://www.iana.org/assignments/scim/__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11P35nQcQ$>. >>>>>>>>>>> Do you prefer to use "Event URI" or "Schema URI"? Note that we >>>>>>>>>>> will communicate any changes to the registry to IANA. >>>>>>>>>>> --> >>>>>>>>>> <PH> >>>>>>>>>> These are actually different uses. EventURIs are used in JWT not in >>>>>>>>>> SCIM protocol itself. SCIM “Schemas” do appear in some SCIM Events >>>>>>>>>> (e.g. urn:ietf:params:scim:event:prov:create:full has a “data” >>>>>>>>>> element that contains schemas. (See Figure 4) >>>>>>>>>> >>>>>>>>>> Not sure if we need better explanation somewhere such as definitions? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 14) <!-- [rfced] The RFC Production Center has been advised that >>>>>>>>>>> "ASCII" >>>>>>>>>>> and not "US-ASCII" should be used. May we change instances of >>>>>>>>>>> "US-ASCII" in this document to "ASCII" as shown below? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> name A US-ASCII string that conforms to URN syntax requirements (see >>>>>>>>>>> [RFC8141]) and defines a descriptive event name (e.g., >>>>>>>>>>> "create"). >>>>>>>>>>> >>>>>>>>>>> other An optional US-ASCII string that conforms to URN syntax >>>>>>>>>>> requirements (see [RFC8141]) and serves as an additional sub- >>>>>>>>>>> category or qualifier. >>>>>>>>>>> >>>>>>>>>>> Perhaps: >>>>>>>>>>> name An ASCII string that conforms to URN syntax requirements (see >>>>>>>>>>> [RFC8141]) and defines a descriptive event name (e.g., >>>>>>>>>>> "create"). >>>>>>>>>>> >>>>>>>>>>> other An optional ASCII string that conforms to URN syntax >>>>>>>>>>> requirements (see [RFC8141]) and serves as an additional sub- >>>>>>>>>>> category or qualifier. >>>>>>>>>>> —> >>>>>>>>>>> >>>>>>>>>> <PH> RFC8141 says ASCII so this change ok >>>>>>>>>>> >>>>>>>>>>> 15) <!--[rfced] The SVG and ASCII artworks of Figure 20 are >>>>>>>>>>> inconsistent >>>>>>>>>>> with each other. Please provide updated artwork for this figure. >>>>>>>>>>> >>>>>>>>>>> (See >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.html*figure-20__;Iw!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv12dgzrm2g$ >>>>>>>>>>> vs. >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.txt__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv103qvMPNA$) >>>>>>>>>>> >>>>>>>>>>> For example, inconsistent labels exist in the html vs. txt outputs: >>>>>>>>>>> >>>>>>>>>>> Client A vs. SCIM Client A >>>>>>>>>>> >>>>>>>>>>> SCIM Service Provider vs. Service Provider >>>>>>>>>>> >>>>>>>>>>> [4] Update local node vs. Update local node [4] >>>>>>>>>>> [Note that in the html output, this text appears outside >>>>>>>>>>> the box, but in the txt output, it appears inside the box.] >>>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 16) <!--[rfced] The SVG and ASCII artwork for Figure 21 are >>>>>>>>>>> inconsistent >>>>>>>>>>> with each other. Please provide updated artwork for this figure. >>>>>>>>>>> >>>>>>>>>>> (See >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.html*figure-21__;Iw!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11_1VTiLA$ >>>>>>>>>>> vs. >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.txt__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv103qvMPNA$) >>>>>>>>>>> >>>>>>>>>>> Examples: >>>>>>>>>>> >>>>>>>>>>> a) Inconsistent labels and positioning of the terms in the html vs. >>>>>>>>>>> txt outputs: >>>>>>>>>>> >>>>>>>>>>> SCIM Client vs. SCIM Clnt (CA) >>>>>>>>>>> SCIM Service Provider vs. SCIM Service Provider (SP) >>>>>>>>>>> Client A Co-op Receiver vs. Client A Co-op Receiver (ER) >>>>>>>>>>> Co-op Action Endpoint vs. Co-op Action Endpoint(LEP) >>>>>>>>>>> [1] SCIM Operation vs. "SCIM Operation" >>>>>>>>>>> [2] SCIM Response vs. "SCIM Response" >>>>>>>>>>> >>>>>>>>>>> [3] Event SCIM:prov:<op> id=xyz vs. "Event SCIM:prov:<op>, id=xyz" >>>>>>>>>>> [Note: There is a dotted line underneath this term in the html >>>>>>>>>>> output >>>>>>>>>>> but no dotted line in the txt output.] >>>>>>>>>>> >>>>>>>>>>> Receiver may accumulate events for periodic action. vs. >>>>>>>>>>> Note: Receiver may accumulate events for periodic action >>>>>>>>>>> [Note: This text appears in a box in the html output and without a >>>>>>>>>>> box in the txt output.] >>>>>>>>>>> >>>>>>>>>>> [4] SCIM GET <id> vs. "SCIM GET <id>" >>>>>>>>>>> [Note: this term appears over the line in the html output but >>>>>>>>>>> next to the line in the txt output.] >>>>>>>>>>> >>>>>>>>>>> [5] Filtered Resource Response vs. "Filtered Resource Resp." >>>>>>>>>>> [Note: This term appears over the line in the html output but >>>>>>>>>>> next to the line in the txt output.] >>>>>>>>>>> >>>>>>>>>>> [6] Co-ordinated Action vs. "Co-ord Action" >>>>>>>>>>> [Note: This term appears over the line in the html output but >>>>>>>>>>> under the line in the txt output.] >>>>>>>>>>> >>>>>>>>>>> b) "loop" (and the box it appears in) is present in the html output >>>>>>>>>>> but is >>>>>>>>>>> missing in the txt output. >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>> <PH> I have made changes as follows: >>>>>>>>>> Figure 20: >>>>>>>>>> - In-doc ASCII: replaced flow-chart style with sequence-diagram >>>>>>>>>> version from figure20.txt (max 70 chars, all under 72) >>>>>>>>>> - In-doc SVG: "Client A" → "SCIM Client A" to match the standalone >>>>>>>>>> SVG and ASCII >>>>>>>>>> - Now all four sources (standalone SVG, standalone TXT, in-doc SVG, >>>>>>>>>> in-doc ASCII) use identical participant names and the same >>>>>>>>>> sequence-diagram visual style >>>>>>>>>> Figure 21 (from previous turn): >>>>>>>>>> - All four sources use "SCIM Client" / "SCIM Service Provider" / >>>>>>>>>> "Event Receiver" / "Co-op Action Endpoint" in matching >>>>>>>>>> sequence-diagram style >>>>>>>>>> >>>>>>>>>> For you edit see the files attached and replace in the XML sections >>>>>>>>>> as appropriate. >>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 17) <!-- [rfced] Please review each artwork element and let us know >>>>>>>>>>> if any should >>>>>>>>>>> be marked as sourcecode (or another element) instead. >>>>>>>>>>> >>>>>>>>>>> Note that we updated <artwork> to <sourcecode> in several sections. >>>>>>>>>>> Please >>>>>>>>>>> confirm that this is correct. >>>>>>>>>>> >>>>>>>>>>> In addition, please consider whether the "type" attribute of any >>>>>>>>>>> sourcecode >>>>>>>>>>> element should be set and/or has been set correctly. >>>>>>>>>>> >>>>>>>>>>> The current list of preferred values for "type" is available at >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/materials/sourcecode-types.txt__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv103T0O_Fg$ >>>>>>>>>>> . If the current >>>>>>>>>>> list does not contain an applicable type, feel free to suggest >>>>>>>>>>> additions >>>>>>>>>>> for consideration. Note that it is also acceptable to leave the >>>>>>>>>>> "type" >>>>>>>>>>> attribute not set. >>>>>>>>>>> —> >>>>>>>>>>> >>>>>>>>>> <PH> >>>>>>>>>> >>>>>>>>>> All of the figures with JSON in them should be changed to >>>>>>>>>> <sourcecode type=“json”> >>>>>>>>>> - Figures 1 through 19 >>>>>>>>>> >>>>>>>>>> Figure 20 and 21 are artwork AFAIK. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 18) <!-- [rfced] Terminology >>>>>>>>>>> >>>>>>>>>>> a) Throughout the text, the following terminology appears to be used >>>>>>>>>>> inconsistently. Please review these occurrences and let us know >>>>>>>>>>> if/how they >>>>>>>>>>> may be made consistent. >>>>>>>>>>> >>>>>>>>>>> Asynchronous SCIM Request vs. asynchronous SCIM request >>>>>>>>>>> (also Asynchronous SCIM Request capability) >>>>>>>>>>> >>>>>>>>>>> Asynchronous Request completion vs. >>>>>>>>>>> asynchronous request completion vs. >>>>>>>>>>> Asynchronous Request Completion Event vs. >>>>>>>>>>> Asynchronous Request Completion event vs. >>>>>>>>>>> asynchronous request completion event vs. >>>>>>>>>>> Asynchronous Event completion event vs. >>>>>>>>>>> Asynchronous Completion event >>>>>>>>>>> >>>>>>>>>>> Event Feed vs. event feed >>>>>>>>>>> >>>>>>>>>>> Event Payload vs. event payload >>>>>>>>>>> [Note: RFC 8417 uses the lowercase forms for "event feed" and >>>>>>>>>>> "event payload". Please also consider if the case should be updated >>>>>>>>>>> for "Event Publisher", "Event Stream", and "Event Receiver".] >>>>>>>>>>> >>>>>>>>>>> Event Receiver vs. receiver >>>>>>>>>>> [Note: Do any of the lowercase forms refer to an "Event Receiver”?] >>>>>>>>>>> >>>>>>>>>> <PH> Thanks. Good catch. I was attempting to follow the practice >>>>>>>>>> of terminology e.g. SHOULD vs should. >>>>>>>>>> >>>>>>>>>> Lower case is appropriate when using it in general langauge. When >>>>>>>>>> referring to the defined thing or in heading I believe proper case >>>>>>>>>> is appropriate. >>>>>>>>>> >>>>>>>>>> E.g. The Event Feed vs passing events to an event feed. >>>>>>>>>> >>>>>>>>>> Thoughts? I am ok proper casing everything if you prefer. >>>>>>>>>> >>>>>>>>>>> b) How may we update these terms for consistency? >>>>>>>>>>> >>>>>>>>>>> Event Feed (or event feed) vs. Feed Event vs. Feed Management event >>>>>>>>>>> >>>>>>>>>>> HTTP Service Endpoint vs. HTTP endpoint >>>>>>>>>>> [Note: Also consider "Event Publisher endpoint”.] >>>>>>>>>>> >>>>>>>>>> <PH> Drop service and just use HTTP endpoint >>>>>>>>>> >>>>>>>>>>> HTTP Status 202 (Accepted) vs. >>>>>>>>>>> HTTP Status 202 Accepted vs. >>>>>>>>>>> HTTP 202 Accepted >>>>>>>>>>> Note: Perhaps (to match usage in RFC 7644): >>>>>>>>>>> HTTP status code 202 (Accepted) >>>>>>>>>>> >>>>>>>>>> <PH> Please match >>>>>>>>>> >>>>>>>>>>> JSON Web Token vs. JSON token >>>>>>>>>>> >>>>>>>>>> <PH> Use JSON Web Token >>>>>>>>>> >>>>>>>>>>> c) We note that some terms that appear as uppercase (or a mix of >>>>>>>>>>> uppercase and lowercase) in this document appear as lowercase in the >>>>>>>>>>> referenced RFCs. Would you like to update the terms below to reflect >>>>>>>>>>> the forms on the right for consistency with the referenced RFCs, or >>>>>>>>>>> do you prefer for these terms to be uppercase throughout the >>>>>>>>>>> document? >>>>>>>>>>> >>>>>>>>>>> SCIM Client -> SCIM client (per RFCs 7643 and 7644) >>>>>>>>>>> SCIM Complex attribute -> SCIM complex attribute (per RFC 7644) >>>>>>>>>>> SCIM Protocol -> SCIM protocol (per RFC 7644) >>>>>>>>>>> SCIM Resource -> SCIM resource (per RFCs 7643 and 7644) >>>>>>>>>>> SCIM Response -> SCIM response (per RFC 7644) >>>>>>>>>>> SCIM Schema -> SCIM schema (per RFC 7643) >>>>>>>>>>> SCIM Service Provider -> SCIM service provider (per RFCs 7643, >>>>>>>>>>> 7644, and 9865) >>>>>>>>>>> >>>>>>>>>> <PH> I believe this is an artificat of changing IETF styles over >>>>>>>>>> time. During the writing of 7644 they didn’t want capitalization. >>>>>>>>>> >>>>>>>>>> Similar to above (regarding is it a term or plain language). I am >>>>>>>>>> ok with going either with proper case “things” or the “SCIM client” >>>>>>>>>> approach defpending on your current style guide. >>>>>>>>>>> d) FYI: We made the following updates for consistency. Please let us >>>>>>>>>>> know if any further updates are needed. >>>>>>>>>>> >>>>>>>>>>> Bulk request -> bulk request (per RFC 7644) >>>>>>>>>>> Etag -> ETag (per RFC 7644) >>>>>>>>>>> HTTP Client -> HTTP client (per RFC 7644) >>>>>>>>>>> HTTP Header -> HTTP header (per RFCs 7240 and 7644) >>>>>>>>>>> SCIM event -> SCIM Event >>>>>>>>>> >>>>>>>>>> ok >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> e) For "Co-ordinated Provisioning", may we remove the hyphen >>>>>>>>>>> to match common spelling of "coordinated"? >>>>>>>>>>> Or, is there some special meaning when using the hyphen? >>>>>>>>>>> (Depending on your reply, we will update the various forms of >>>>>>>>>>> 'coordination' in this document.) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> yes >>>>>>>>>> >>>>>>>>>>> f) We note the following variance: >>>>>>>>>>> Co-ordinated Provisioning (CP) vs. Co-operative Provisioning (CP) >>>>>>>>>>> >>>>>>>>>>> May the 2 instances of "Co-operative Provisioning" be updated to >>>>>>>>>>> "Coordinated Provisioning" (note: "operative" to "ordinated")? >>>>>>>>>>> In other words, we suggest: >>>>>>>>>>> >>>>>>>>>>> Section 2.3 >>>>>>>>>>> This section defines events related to changes in the content of an >>>>>>>>>>> event feed such as SCIM Resources that are being added or removed >>>>>>>>>>> from an event feed or events used in Coordinated Provisioning >>>>>>>>>>> scenarios where only a subset of entities are shared across an Event >>>>>>>>>>> Feed. >>>>>>>>>>> >>>>>>>>>>> Section 2.4 >>>>>>>>>>> These events are used in both Domain-Based Replication (DBR) and >>>>>>>>>>> Coordinated Provisioning (CP) mode. >>>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> <PH> ok >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 19) <!-- [rfced] FYI - We have added expansions for abbreviations >>>>>>>>>>> upon first use >>>>>>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review >>>>>>>>>>> these and each >>>>>>>>>>> expansion in the document carefully to ensure correctness. >>>>>>>>>>> >>>>>>>>>>> JSON Web Signature (JWS) >>>>>>>>>>> Globally Unique Identifier (GUID) >>>>>>>>>>> —> >>>>>>>>>>> >>>>>>>>>> <PH> thanks >>>>>>>>>>> >>>>>>>>>>> 20) <!-- [rfced] Please review the "Inclusive Language" portion of >>>>>>>>>>> the online >>>>>>>>>>> Style Guide >>>>>>>>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv13_gcSrhA$ >>>>>>>>>>> > >>>>>>>>>>> and let us know if any changes are needed. Updates of this nature >>>>>>>>>>> typically >>>>>>>>>>> result in more precise language, which is helpful for readers. >>>>>>>>>>> >>>>>>>>>>> Note that our script did not flag any words in particular, but this >>>>>>>>>>> should >>>>>>>>>>> still be reviewed as a best practice. >>>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> <PH> I am not aware of any issues according to the examples in the >>>>>>>>>> links provided. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thank you. >>>>>>>>>>> >>>>>>>>>>> Karen Moore and Alice Russo >>>>>>>>>>> RFC Production Center >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On May 1, 2026, [email protected] wrote: >>>>>>>>>>> >>>>>>>>>>> *****IMPORTANT***** >>>>>>>>>>> >>>>>>>>>>> Updated 2026/05/01 >>>>>>>>>>> >>>>>>>>>>> RFC Author(s): >>>>>>>>>>> -------------- >>>>>>>>>>> >>>>>>>>>>> Instructions for Completing AUTH48 >>>>>>>>>>> >>>>>>>>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>>>>>>>> approved by you and all coauthors, it will be published as an RFC. >>>>>>>>>>> If an author is no longer available, there are several remedies >>>>>>>>>>> available as listed in the FAQ >>>>>>>>>>> (https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv10clvyS_A$ >>>>>>>>>>> ). >>>>>>>>>>> >>>>>>>>>>> You and you coauthors are responsible for engaging other parties >>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>>>>>>>> your approval. >>>>>>>>>>> >>>>>>>>>>> Planning your review >>>>>>>>>>> --------------------- >>>>>>>>>>> >>>>>>>>>>> Please review the following aspects of your document: >>>>>>>>>>> >>>>>>>>>>> * RFC Editor questions >>>>>>>>>>> >>>>>>>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>>>>>>> that have been included in the XML file as comments marked as >>>>>>>>>>> follows: >>>>>>>>>>> >>>>>>>>>>> <!-- [rfced] ... --> >>>>>>>>>>> >>>>>>>>>>> These questions will also be sent in a subsequent email. >>>>>>>>>>> >>>>>>>>>>> * Changes submitted by coauthors >>>>>>>>>>> >>>>>>>>>>> Please ensure that you review any changes submitted by your >>>>>>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>>>>>> agree to changes submitted by your coauthors. >>>>>>>>>>> >>>>>>>>>>> * Content >>>>>>>>>>> >>>>>>>>>>> Please review the full content of the document, as this cannot >>>>>>>>>>> change once the RFC is published. Please pay particular attention >>>>>>>>>>> to: >>>>>>>>>>> - IANA considerations updates (if applicable) >>>>>>>>>>> - contact information >>>>>>>>>>> - references >>>>>>>>>>> >>>>>>>>>>> * Copyright notices and legends >>>>>>>>>>> >>>>>>>>>>> Please review the copyright notice and legends as defined in >>>>>>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>>>>>> (TLP – >>>>>>>>>>> https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11Mdq7yZQ$ >>>>>>>>>>> ). >>>>>>>>>>> >>>>>>>>>>> * Semantic markup >>>>>>>>>>> >>>>>>>>>>> Please review the markup in the XML file to ensure that elements of >>>>>>>>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>>>>>>>> and <artwork> are set correctly. See details at >>>>>>>>>>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv13JjZqjPg$ >>>>>>>>>>> >. >>>>>>>>>>> >>>>>>>>>>> * Formatted output >>>>>>>>>>> >>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>>>>>> formatted output, as generated from the markup in the XML file, is >>>>>>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>>>>>> limitations compared to the PDF and HTML. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Submitting changes >>>>>>>>>>> ------------------ >>>>>>>>>>> >>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as >>>>>>>>>>> all >>>>>>>>>>> the parties CCed on this message need to see your changes. The >>>>>>>>>>> parties >>>>>>>>>>> include: >>>>>>>>>>> >>>>>>>>>>> * your coauthors >>>>>>>>>>> >>>>>>>>>>> * [email protected] (the RPC team) >>>>>>>>>>> >>>>>>>>>>> * other document participants, depending on the stream (e.g., >>>>>>>>>>> IETF Stream participants are your working group chairs, the >>>>>>>>>>> responsible ADs, and the document shepherd). >>>>>>>>>>> >>>>>>>>>>> * [email protected], which is a new archival mailing >>>>>>>>>>> list >>>>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>>>>>>> list: >>>>>>>>>>> >>>>>>>>>>> * More info: >>>>>>>>>>> >>>>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11JWUMTDg$ >>>>>>>>>>> >>>>>>>>>>> * The archive itself: >>>>>>>>>>> >>>>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv12GOJ4OXw$ >>>>>>>>>>> >>>>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive >>>>>>>>>>> matter). >>>>>>>>>>> If needed, please add a note at the top of the message that you >>>>>>>>>>> have dropped the address. When the discussion is concluded, >>>>>>>>>>> [email protected] will be re-added to the CC list and >>>>>>>>>>> its addition will be noted at the top of the message. >>>>>>>>>>> >>>>>>>>>>> You may submit your changes in one of two ways: >>>>>>>>>>> >>>>>>>>>>> An update to the provided XML file >>>>>>>>>>> — OR — >>>>>>>>>>> An explicit list of changes in this format >>>>>>>>>>> >>>>>>>>>>> Section # (or indicate Global) >>>>>>>>>>> >>>>>>>>>>> OLD: >>>>>>>>>>> old text >>>>>>>>>>> >>>>>>>>>>> NEW: >>>>>>>>>>> new text >>>>>>>>>>> >>>>>>>>>>> You do not need to reply with both an updated XML file and an >>>>>>>>>>> explicit >>>>>>>>>>> list of changes, as either form is sufficient. >>>>>>>>>>> >>>>>>>>>>> We will ask a stream manager to review and approve any changes that >>>>>>>>>>> seem >>>>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of >>>>>>>>>>> text, >>>>>>>>>>> and technical changes. Information about stream managers can be >>>>>>>>>>> found in >>>>>>>>>>> the FAQ. Editorial changes do not require approval from a stream >>>>>>>>>>> manager. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Approving for publication >>>>>>>>>>> -------------------------- >>>>>>>>>>> >>>>>>>>>>> To approve your RFC for publication, please reply to this email >>>>>>>>>>> stating >>>>>>>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>>>>>>>> as all the parties CCed on this message need to see your approval. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Files >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> The files are available here: >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.xml__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv13xS_DYZQ$ >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11HOZW8Ng$ >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.pdf__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv138UdRaTA$ >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.txt__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv103qvMPNA$ >>>>>>>>>>> >>>>>>>>>>> Diff file of the text: >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-diff.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv13pzUjN2w$ >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-rfcdiff.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11TjA_l9w$ >>>>>>>>>>> (side by side) >>>>>>>>>>> >>>>>>>>>>> Diff of the XML: >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-xmldiff1.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv13Z43qhoA$ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Tracking progress >>>>>>>>>>> ----------------- >>>>>>>>>>> >>>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9967__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv110ODAcOg$ >>>>>>>>>>> >>>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>>> >>>>>>>>>>> Thank you for your cooperation, >>>>>>>>>>> >>>>>>>>>>> RFC Editor >>>>>>>>>>> >>>>>>>>>>> -------------------------------------- >>>>>>>>>>> RFC9967 (draft-ietf-scim-events-16) >>>>>>>>>>> >>>>>>>>>>> Title : SCIM Profile for Security Event Tokens >>>>>>>>>>> Author(s) : P. Hunt, Ed., N. Cam-Winget, M. Kiser, J. >>>>>>>>>>> Schreiber >>>>>>>>>>> WG Chair(s) : Nancy Cam-Winget >>>>>>>>>>> Area Director(s) : Deb Cooley, Christopher Inacio >>>>> >>>>> >>> >> >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
