Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
From: Karen Moore <kmoore@staff.rfc-editor.org>
In-Reply-To: 
 <PH3PPF6E8D29981C9CF31BD54DA75AF8D48D63D2@PH3PPF6E8D29981.namprd11.prod.outlook.com>
Date: Fri, 8 May 2026 11:00:26 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <156F0774-3A27-4C06-B522-CD3B3ACAFF46@staff.rfc-editor.org>
References: <20260501221703.8FD79315D02@rfcpa.rfc-editor.org>
 <B27C83F2-A4CC-4DB3-9CF3-749FF9A11199@independentid.com>
 <A438B49A-2507-4DED-9A93-A31357C4C655@staff.rfc-editor.org>
 <81B3B427-5545-4AC0-8520-DAB5DBB2621A@independentid.com>
 <04AFC1F3-E73B-4B6A-BE23-0E9A092590DB@staff.rfc-editor.org>
 <BYAPR04MB4024A05F15931B897E652A598C3F2@BYAPR04MB4024.namprd04.prod.outlook.com>
 <6073CCDA-F0FB-454C-97D4-56D0EA208DA1@staff.rfc-editor.org>
 <0071D208-0A63-426E-A9C4-5B3692AE323F@independentid.com>
 <41602873-A8AF-4697-B33B-1C1B2A62D505@staff.rfc-editor.org>
 <CAPpuNHncwUwFcKTHKgXuPgeP0MyKsB=dfNnjKkQZN7ejsKNUyQ@mail.gmail.com>
 <BYAPR04MB40247FAE50310ECE643961D78C3C2@BYAPR04MB4024.namprd04.prod.outlook.com>
 <74321DC7-1019-4F40-A72D-82B79446DFB4@staff.rfc-editor.org>
 <PH3PPF6E8D29981C9CF31BD54DA75AF8D48D63D2@PH3PPF6E8D29981.namprd11.prod.outlook.com>
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>,
 Jen Schreiber <jwschreib@gmail.com>,
 Mike Kiser <mike.kiser@sailpoint.com>,
 "jen@sgnl.ai" <jen@sgnl.ai>,
 Phillip Hunt <phil.hunt@independentid.com>
Message-ID-Hash: 56GSMGU2ZAL74FPP4KQBMARY4PBETWGL
CC: "debcooley1@gmail.com" <debcooley1@gmail.com>,
 "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>,
 "scim-ads@ietf.org" <scim-ads@ietf.org>,
 "scim-chairs@ietf.org" <scim-chairs@ietf.org>,
 "lear@cisco.com" <lear@cisco.com>,
 "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Precedence: list
Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_AUTH48=3A_RFC-to-be_9967_=3Cdraft-ietf-scim-eve?=
 =?utf-8?q?nts-16=3E_for_your_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/auth48archive/V-mTsBpg--Hgh9ZVQpLzedzJD0c>

Hi Nancy and Jen,

Thank you for your replies.  We have noted Nancy=E2=80=99s 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=E2=80=AFPM, Nancy Cam-Winget (ncamwing) =
<ncamwing@cisco.com> wrote:
>=20
>=20
> Apologies for the delays, but I approve of the document=E2=80=A6.thanks.=
  - Nancy
> From: Karen Moore <kmoore@staff.rfc-editor.org>
> Date: Thursday, May 7, 2026 at 1:45=E2=80=AFPM
> To: debcooley1@gmail.com <debcooley1@gmail.com>; Mike Kiser =
<mike.kiser@sailpoint.com>; Jen Schreiber <jwschreib@gmail.com>; Phillip =
Hunt <phil.hunt@independentid.com>; Nancy Cam-Winget (ncamwing) =
<ncamwing@cisco.com>
> Cc: jen@sgnl.ai <jen@sgnl.ai>; rfc-editor@rfc-editor.org =
<rfc-editor@rfc-editor.org>; scim-ads@ietf.org <scim-ads@ietf.org>; =
scim-chairs@ietf.org <scim-chairs@ietf.org>; lear@cisco.com =
<lear@cisco.com>; auth48archive@rfc-editor.org =
<auth48archive@rfc-editor.org>
> Subject: Re: [AD] AUTH48: RFC-to-be 9967 <draft-ietf-scim-events-16> =
for your review
>=20
> Hi Deb, Mike, and *Jen,
>=20
> Thank you for your replies. We have noted approval of the document for =
each of you at <https://www.rfc-editor.org/auth48/rfc9967>.=20
>=20
> 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.
>=20
> *Jen, we updated your email address. For your affiliation, would you =
like to remove or replace =E2=80=9CWorkday=E2=80=9D?
>=20
>=20
> =E2=80=94Files (please refresh)=E2=80=94
>=20
> Updated XML file:
> https://www.rfc-editor.org/authors/rfc9967.xml
>=20
> 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
>=20
> 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)
>=20
> 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)
>=20
> 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)
>=20
> Best regards,
>=20
> Karen Moore
> RFC Production Center
>=20
>=20
> > On May 7, 2026, at 3:37=E2=80=AFAM, Deb Cooley =
<debcooley1@gmail.com> wrote:
> >
> > I approve.
> >
> > Deb Cooley
>=20
> > On May 6, 2026, at 6:14=E2=80=AFPM, Mike Kiser =
<mike.kiser@sailpoint.com> wrote:
> >
> > I approve of the document as well.
> >
> > -Mike
> >
> > Get Outlook for iOSFrom: Jen Schreiber <jwschreib@gmail.com>
> > Sent: Wednesday, May 6, 2026 7:08:38 PM
> > To: Karen Moore <kmoore@staff.rfc-editor.org>
> > Cc: debcooley1@gmail.com <debcooley1@gmail.com>; Phillip Hunt =
<phil.hunt@independentid.com>; Mike Kiser <mike.kiser@sailpoint.com>; =
Nancy Cam-Winget <ncamwing@cisco.com>; jen@sgnl.ai <jen@sgnl.ai>; =
rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>; scim-ads@ietf.org =
<scim-ads@ietf.org>; scim-chairs@ietf.org <scim-chairs@ietf.org>; =
lear@cisco.com <lear@cisco.com>; auth48archive@rfc-editor.org =
<auth48archive@rfc-editor.org>
> > 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 =
jwschreib@gmail.com?
> >
> > Thank you,
> > Jen
> >
> > On Wed, May 6, 2026 at 5:04=E2=80=AFPM Karen Moore =
<kmoore@staff.rfc-editor.org> 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.
> >
> >
> > =E2=80=94Files (please refresh)=E2=80=94
> >
> > 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=E2=80=AFPM, Phillip Hunt =
<phil.hunt@independentid.com> wrote:
> > >
> > > Looks good to me.  Thanks!
> > >
> > > Phil
> > > phil.hunt@independentid.com
> > >
> > >
> > >> On May 6, 2026, at 2:29=E2=80=AFPM, Karen Moore =
<kmoore@staff.rfc-editor.org> wrote:
> > >>
> > >> Hi Phil and Mike,
> > >>
> > >> Thank you for your replies.  Once we have Jennifer=E2=80=99s =
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=E2=80=9D?]
> > >> 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)
> > >>
> > >> =E2=80=94Files (please refresh)=E2=80=94
> > >>
> > >> 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=E2=80=AFAM, Mike Kiser =
<mike.kiser@sailpoint.com> 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 <kmoore@staff.rfc-editor.org>
> > >>> Sent: Tuesday, May 5, 2026 20:05
> > >>> To: Phillip Hunt <phil.hunt@independentid.com>
> > >>> Cc: jennifer.winer=3D40workday.com@dmarc.ietf.org =
<jennifer.winer=3D40workday.com@dmarc.ietf.org>; Mike Kiser =
<mike.kiser@sailpoint.com>; Nancy Cam-Winget <ncamwing@cisco.com>; =
jennifer.winer@workday.com<jennifer.winer@workday.com>; =
rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>; scim-ads@ietf.org =
<scim-ads@ietf.org>; scim-chairs@ietf.org <scim-chairs@ietf.org>; =
lear@cisco.com =
<lear@cisco.com>;debcooley1@gmail.com<debcooley1@gmail.com>; =
auth48archive@rfc-editor.org <auth48archive@rfc-editor.org>
> > >>> 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=E2=80=AFPM, Phillip Hunt =
<phil.hunt@independentid.com> wrote:
> > >>>>
> > >>>> We also might want to change Jennifer=E2=80=99s email as it is =
bouncing.
> > >>>>
> > >>>> Phil
> > >>>> phil.hunt@independentid.com
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>> On May 5, 2026, at 1:49=E2=80=AFPM, Karen Moore =
<kmoore@staff.rfc-editor.org> 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=E2=80=9D, "Schema URI=E2=80=9D, 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/__;!!Ms=
NKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk6=
3HVTDGWE6vyoevHv11P35nQcQ$>.
> > >>>>>> 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 =E2=80=9CSchemas=E2=80=9D do =
appear in some SCIM Events
> > >>>>>> (e.g. urn:ietf:params:scim:event:prov:create:full has a =
=E2=80=9Cdata=E2=80=9D 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=E2=80=9D be =E2=80=9CCoord. Action Endpoint=E2=80=9D?
> > >>>>>
> > >>>>> =E2=80=94Files=E2=80=94
> > >>>>>
> > >>>>> 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-cAuHE7O1dZBh9jqOTdp6P=
3d1bXk63HVTDGWE6vyoevHv13xS_DYZQ$
> > >>>>>
> > >>>>> Updated output files:
> > >>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.txt=
__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P=
3d1bXk63HVTDGWE6vyoevHv103qvMPNA$
> > >>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.pdf=
__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P=
3d1bXk63HVTDGWE6vyoevHv138UdRaTA$
> > >>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.htm=
l__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6=
P3d1bXk63HVTDGWE6vyoevHv11HOZW8Ng$
> > >>>>>
> > >>>>> Diff files showing all changes made during AUTH48:
> > >>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-aut=
h48diff.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1d=
ZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv133m8cO-g$
> > >>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-aut=
h48rfcdiff.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7=
O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv13CfpbtNg$ (side by side)
> > >>>>>
> > >>>>> Diff files showing all changes:
> > >>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-dif=
f.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jq=
OTdp6P3d1bXk63HVTDGWE6vyoevHv13pzUjN2w$
> > >>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-rfc=
diff.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh=
9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11TjA_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-cAuHE7O1dZBh9jqOTdp6P3d1bX=
k63HVTDGWE6vyoevHv110ODAcOg$
> > >>>>>
> > >>>>> Best regards,
> > >>>>>
> > >>>>> Karen Moore
> > >>>>> RFC Production Center
> > >>>>>
> > >>>>>
> > >>>>>> On May 3, 2026, at 1:25=E2=80=AFPM, Phillip Hunt =
<phil.hunt@independentid.com> 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.
> > >>>>>>
> > >>>>>> =E2=80=94> co-authors, please check as well per the =
instructions in the previous email.
> > >>>>>>
> > >>>>>> Phil
> > >>>>>> phil.hunt@independentid.com
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>> On May 1, 2026, at 3:17=E2=80=AFPM, =
rfc-editor@rfc-editor.org 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...
> > >>>>>>> =E2=80=94>
> > >>>>>>>
> > >>>>>> <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"
> > >>>>>>> =E2=80=94
> > >>>>>>>
> > >>>>>> <PH> Just an example, doesn=E2=80=99t 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.
> > >>>>>>> =E2=80=94>
> > >>>>>>>
> > >>>>>> <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/__;!!Ms=
NKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk6=
3HVTDGWE6vyoevHv11P35nQcQ$>.
> > >>>>>>> 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 =E2=80=9CSchemas=E2=80=9D do appear in =
some SCIM Events (e.g. urn:ietf:params:scim:event:prov:create:full has a =
=E2=80=9Cdata=E2=80=9D 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.
> > >>>>>>> =E2=80=94>
> > >>>>>>>
> > >>>>>> <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.htm=
l*figure-20__;Iw!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1=
dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv12dgzrm2g$
> > >>>>>>> vs. =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.txt=
__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P=
3d1bXk63HVTDGWE6vyoevHv103qvMPNA$)
> > >>>>>>>
> > >>>>>>> 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.htm=
l*figure-21__;Iw!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1=
dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11_1VTiLA$
> > >>>>>>> vs. =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.txt=
__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P=
3d1bXk63HVTDGWE6vyoevHv103qvMPNA$)
> > >>>>>>>
> > >>>>>>> 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=3Dxyz vs. "Event SCIM:prov:<op>, =
id=3Dxyz"
> > >>>>>>> [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" =E2=86=92 "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/sourcecod=
e-types.txt__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZ=
Bh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv103T0O_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.
> > >>>>>>> =E2=80=94>
> > >>>>>>>
> > >>>>>> <PH> =20
> > >>>>>>
> > >>>>>> All of the figures with JSON in them should be changed to =
<sourcecode type=3D=E2=80=9Cjson=E2=80=9D>
> > >>>>>> - 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.=20
> > >>>>>>>
> > >>>>>>> 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=E2=80=9D?]
> > >>>>>>>
> > >>>>>> <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=E2=80=9D.]
> > >>>>>>>
> > >>>>>> <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=E2=80=99t want =
capitalization.
> > >>>>>>
> > >>>>>> Similar to above (regarding is it a term or plain language).  =
I am ok with going either with proper case =E2=80=9Cthings=E2=80=9D or =
the =E2=80=9CSCIM client=E2=80=9D 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)
> > >>>>>>> =E2=80=94>
> > >>>>>>>
> > >>>>>> <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-c=
AuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv13_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, rfc-editor@rfc-editor.org 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.=20
> > >>>>>>> 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/__;!!MsNKLpFGs=
w!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGW=
E6vyoevHv10clvyS_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 =E2=80=93 =
https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!MsNK=
LpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63H=
VTDGWE6vyoevHv11Mdq7yZQ$ ).
> > >>>>>>>
> > >>>>>>> *  Semantic markup
> > >>>>>>>
> > >>>>>>> Please review the markup in the XML file to ensure that =
elements of=20
> > >>>>>>> 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-cAuHE7O1dZBh9jqOTdp6P3d1=
bXk63HVTDGWE6vyoevHv13JjZqjPg$ >.
> > >>>>>>>
> > >>>>>>> *  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 =E2=80=98R=
EPLY ALL=E2=80=99 as all
> > >>>>>>> the parties CCed on this message need to see your changes. =
The parties
> > >>>>>>> include:
> > >>>>>>>
> > >>>>>>> *  your coauthors
> > >>>>>>>
> > >>>>>>> *  rfc-editor@rfc-editor.org (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).
> > >>>>>>>
> > >>>>>>> *  auth48archive@rfc-editor.org, 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-ann=
ounce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdy=
GlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11JWUMTDg$
> > >>>>>>>
> > >>>>>>>  *  The archive itself:
> > >>>>>>>     =
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth4=
8archive/__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh=
9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv12GOJ4OXw$
> > >>>>>>>
> > >>>>>>>  *  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,
> > >>>>>>>     auth48archive@rfc-editor.org 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
> > >>>>>>> =E2=80=94 OR =E2=80=94
> > >>>>>>> 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 =
=E2=80=98REPLY ALL=E2=80=99,
> > >>>>>>> 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-cAuHE7O1dZBh9jqOTdp6P=
3d1bXk63HVTDGWE6vyoevHv13xS_DYZQ$
> > >>>>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.htm=
l__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6=
P3d1bXk63HVTDGWE6vyoevHv11HOZW8Ng$
> > >>>>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.pdf=
__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P=
3d1bXk63HVTDGWE6vyoevHv138UdRaTA$
> > >>>>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967.txt=
__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jqOTdp6P=
3d1bXk63HVTDGWE6vyoevHv103qvMPNA$
> > >>>>>>>
> > >>>>>>> Diff file of the text:
> > >>>>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-dif=
f.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh9jq=
OTdp6P3d1bXk63HVTDGWE6vyoevHv13pzUjN2w$
> > >>>>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-rfc=
diff.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZBh=
9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv11TjA_l9w$  (side by side)
> > >>>>>>>
> > >>>>>>> Diff of the XML:
> > >>>>>>> =
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9967-xml=
diff1.html__;!!MsNKLpFGsw!Jtn9GmNkmCD9jKoTJunoAZzdyGlUNrmLDCMX-cAuHE7O1dZB=
h9jqOTdp6P3d1bXk63HVTDGWE6vyoevHv13Z43qhoA$
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> 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-cAuHE7O1dZBh9jqOTdp6P3d1bX=
k63HVTDGWE6vyoevHv110ODAcOg$
> > >>>>>>>
> > >>>>>>> Please let us know if you have any questions.=20
> > >>>>>>>
> > >>>>>>> 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
> > >
> > >
>=20