Content-Type: multipart/mixed;
	boundary="Apple-Mail=_430BFA40-08C6-4410-B701-9AF045F70A1B"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
From: Karen Moore <kmoore@staff.rfc-editor.org>
In-Reply-To: <B27C83F2-A4CC-4DB3-9CF3-749FF9A11199@independentid.com>
Date: Tue, 5 May 2026 13:49:12 -0700
Message-Id: <A438B49A-2507-4DED-9A93-A31357C4C655@staff.rfc-editor.org>
References: <20260501221703.8FD79315D02@rfcpa.rfc-editor.org>
 <B27C83F2-A4CC-4DB3-9CF3-749FF9A11199@independentid.com>
To: Phillip Hunt <phil.hunt@independentid.com>,
 mike.kiser@sailpoint.com,
 Nancy Cam-Winget <ncamwing@cisco.com>,
 jennifer.winer@workday.com
Message-ID-Hash: 2I47MJIMONEND4K7QJ4XNOW54BZORZ4B
CC: rfc-editor@rfc-editor.org, scim-ads@ietf.org, scim-chairs@ietf.org,
 lear@cisco.com, debcooley1@gmail.com, auth48archive@rfc-editor.org
Precedence: list
Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_questions_-_Re=3A_AUTH48=3A_RFC-to-be_9967_=3Cd?=
 =?utf-8?q?raft-ietf-scim-events-16=3E_for_your_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/auth48archive/I4X7LqLtzu8TgxUJvdNrrJSnZBM>


--Apple-Mail=_430BFA40-08C6-4410-B701-9AF045F70A1B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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://www.iana.org/assignments/scim/>.=20=

> Do you prefer to use "Event URI" or "Schema URI"?  Note that we=20
> will communicate any changes to the registry to IANA.=20
>=20
> <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)
>=20
> 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=20

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://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 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 3, 2026, at 1:25=E2=80=AFPM, Phillip Hunt =
<phil.hunt@independentid.com> wrote:
>=20
>=20
> Thank you very much for the feedback!
>=20
> 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.
>=20
> 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
>=20
> Let me know if there is anything else.
>=20
> =E2=80=94> co-authors, please check as well per the instructions in =
the previous email.
>=20
> Phil
> phil.hunt@independentid.com
>=20
>=20
>=20
>=20
>=20
>=20
>> On May 1, 2026, at 3:17=E2=80=AFPM, rfc-editor@rfc-editor.org wrote:
>>=20
>> Authors,
>>=20
>> While reviewing this document during AUTH48, please resolve (as =
necessary) the following questions, which are also in the source file.
>>=20
>> 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.
>>=20
>> Original (document title):
>>   SCIM Profile for Security Event Tokens
>>=20
>> Current:=20
>>   System for Cross-domain Identity Management (SCIM) Profile for=20
>>   Security Event Tokens (SETs)
>>=20
>> ...
>> Original (short title):
>>   draft-ietf-scim-events-16
>>=20
>> Current:
>>   SCIM Profile for SETs
>> -->  =20
>>=20
> <PH> oik
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>> -->
>=20
> <PH>  No opinions.  I thought RFC numbers not allowed in abstracts.  =
:)
>>=20
>>=20
>> 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?
>>=20
>> 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).
>>=20
>>   Using the HTTP protocol, a SCIM Protocol Client issues commands...
>>=20
>> 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).
>>=20
>>  Using the HTTP protocol, a SCIM client issues commands...
>> =E2=80=94>
>>=20
> <PH> ok
>>=20
>> 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?
>>=20
>> 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.
>>=20
>> 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
>>=20
>>=20
>> 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.
>>=20
>> Original:
>>   SET:  Abbreviation for "Security Event Token" as defined in =
[RFC8417]
>>=20
>> Current:
>>   Security Event Token (SET):  As defined in [RFC8417].
>> -->
>>=20
> <PH> ok
>>=20
>>=20
>> 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?
>>=20
>> One example
>>=20
>> Original:
>>   uri
>>      The SCIM relative path for the resource which usually consists =
of
>>      the resource type endpoint plus the resource "id" ...
>>=20
>> Perhaps
>>   uri:
>>      The SCIM relative path for the resource that usually consists of
>>      the resource type endpoint plus the resource "id" ...
>> -->
> <PH> no objection
>>=20
>>=20
>> 7) <!--[rfced] Section 3.1 of [RFC7643] uses "id" rather than "Id". =
Is an
>> update needed in this sentence for consistency?
>>=20
>> 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.
>>=20
>> 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
>>=20
>>=20
>> 8) <!-- [rfced] Section 4 of [RFC7643] uses "userName" rather than
>> "username" when referring to the attribute. Should this text
>> be updated accordingly?
>>=20
>> 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.=20=

>>=20
>> Perhaps:
>>   For example, attributes such as "emails" or "userName" (defined in
>>   Section 4 of [RFC7643]) are unique with in a SCIM Service Provider.=20=

>>=20
>> ...
>> Section 2.2
>> Current:
>>   For example: "attributes": ["username","emails","name.familyName"]
>>=20
>> Perhaps:
>>   For example: "attributes": ["userName","emails","name.familyName"]
>> -->
>=20
> <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.
>>=20
>>=20
>> 9) <!--[rfced] FYI, in Section 2.2 about "attributes", please review:
>> - removed the extraneous '>' in '"path">'. Seems it was a typo.=20
>> - removed the line break after "For example:". If you prefer that
>>  the example be in a sourcecode element, please let us know.
>>=20
>> Original:
>>   Names of modified attributes SHOULD conform to the ABNF syntax rule
>>   for "path"> (Section 3.5.2 of [RFC7644]).=20
>>   For example:
>>   "attributes": ["username","emails","name.familyName"]
>>=20
>> Current:
>>   Names of modified attributes SHOULD conform to the ABNF syntax
>>   rule for "path" (see Section 3.5.2 of [RFC7644] and [RFC5234]).=20
>>   For example: "attributes": ["username","emails","name.familyName"].
>> -->
>>=20
>>=20
> <PH> thanks. correct.
>=20
>> 10) <!--[rfced] Should the middle initial for Barbara Jensen III be =
"J."
>> (with a period) in Figure 12, or is the current text correct?
>>=20
>> Current:
>> "formatted":"Ms. Barbara J Jensen III"
>>=20
>> Perhaps:
>> "formatted":"Ms. Barbara J. Jensen III" =20
>> =E2=80=94
>>=20
> <PH> Just an example, doesn=E2=80=99t matter.  The example in Figure 2 =
of RFC7643 has no period.
>>=20
>> 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>
>>=20
> <PH> How about "Async SCIM Request With Prefer Header"
>>=20
>> 12) <!--[rfced] The following sentence does not parse. Please let us =
know
>> how we may update for clarity.
>>=20
>> Original:
>>    Providing the exact date of each membership change is not critical
>>    but instead that the information content remains intact.
>> -->
>=20
> <PH> Proposed:
>=20
> 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>
>>=20
>>=20
>> 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://www.iana.org/assignments/scim/>.=20=

>> Do you prefer to use "Event URI" or "Schema URI"?  Note that we=20
>> will communicate any changes to the registry to IANA.=20
>> --> =20
> <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)
>=20
> Not sure if we need better explanation somewhere such as definitions?
>=20
>>=20
>>=20
>> 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?
>>=20
>> Original:
>>  name   A US-ASCII string that conforms to URN syntax requirements =
(see
>>         [RFC8141]) and defines a descriptive event name (e.g.,
>>         "create").
>>=20
>>  other  An optional US-ASCII string that conforms to URN syntax
>>         requirements (see [RFC8141]) and serves as an additional sub-
>>         category or qualifier.=20
>>=20
>> Perhaps:
>>  name   An ASCII string that conforms to URN syntax requirements (see
>>         [RFC8141]) and defines a descriptive event name (e.g.,
>>         "create").
>>=20
>>  other  An optional ASCII string that conforms to URN syntax
>>         requirements (see [RFC8141]) and serves as an additional sub-
>>         category or qualifier.=20
>> =E2=80=94>
>>=20
> <PH>  RFC8141 says ASCII so this change ok
>>=20
>> 15) <!--[rfced] The SVG and ASCII artworks of Figure 20 are =
inconsistent
>> with each other. Please provide updated artwork for this figure.
>>=20
>> (See https://www.rfc-editor.org/authors/rfc9967.html#figure-20
>> vs. https://www.rfc-editor.org/authors/rfc9967.txt)
>>=20
>> For example, inconsistent labels exist in the html vs. txt outputs:=20=

>>=20
>>  Client A vs. SCIM Client A=20
>>=20
>>  SCIM Service Provider vs. Service Provider
>>=20
>>  [4] Update local node vs. Update local node [4]
>>    [Note that in the html output, this text appears outside=20
>>    the box, but in the txt output, it appears inside the box.]
>> -->
>=20
>>=20
>>=20
>> 16) <!--[rfced] The SVG and ASCII artwork for Figure 21 are =
inconsistent
>> with each other. Please provide updated artwork for this figure.
>>=20
>> (See https://www.rfc-editor.org/authors/rfc9967.html#figure-21
>> vs. https://www.rfc-editor.org/authors/rfc9967.txt)
>>=20
>> Examples:
>>=20
>> a) Inconsistent labels and positioning of the terms in the html vs. =
txt outputs:=20
>>=20
>>  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"
>>=20
>>  [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=20
>>     but no dotted line in the txt output.]
>>=20
>>  Receiver may accumulate events for periodic action. vs.
>>   Note: Receiver may accumulate events for periodic action=20
>>     [Note: This text appears in a box in the html output and without =
a
>>     box in the txt output.]
>>=20
>>  [4] SCIM GET <id> vs. "SCIM GET <id>"
>>     [Note: this term appears over the line in the html output but=20
>>     next to the line in the txt output.]
>>=20
>>  [5] Filtered Resource Response vs. "Filtered Resource Resp."
>>     [Note: This term appears over the line in the html output but=20
>>     next to the line in the txt output.]
>>=20
>>  [6] Co-ordinated Action vs. "Co-ord Action"
>>      [Note: This term appears over the line in the html output but=20
>>      under the line in the txt output.]
>>=20
>> b) "loop" (and the box it appears in) is present in the html output =
but is=20
>> missing in the txt output.
>> -->
>>=20
> <PH>  I have made changes as follows:
>   Figure 20:                                                           =
                                                                         =
                                                                         =
                                                                         =
                                                                         =
                                                                         =
    =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                                                 =
                                                                         =
                                                                         =
                                                                         =
                                                                         =
                 =20
>   - 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                                            =
                                                                         =
                                                                         =
                                                                         =
                 =20
>                                                                        =
                                                                         =
                                                                         =
                                                                         =
                                                                         =
                                                                         =
       Figure 21 (from previous turn):                                   =
                                                                         =
                                                                         =
                                                                         =
                                                                         =
                                                                         =
       =20
>   - All four sources use "SCIM Client" / "SCIM Service Provider" / =
"Event Receiver" / "Co-op Action Endpoint" in matching sequence-diagram =
style     =20
>=20
> For you edit see the files attached and replace in the XML sections as =
appropriate.=

--Apple-Mail=_430BFA40-08C6-4410-B701-9AF045F70A1B
Content-Disposition: inline;
	filename=figure21.svg
Content-Type: image/svg+xml;
	x-unix-mode=0644;
	name="figure21.svg"
Content-Transfer-Encoding: 7bit

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" viewBox="0 0 912.0 857.0">

    <!-- Generator: Sequence Diagram - v1.8.11-(198) - http://www.macsequencediagram.com -->

    <rect x="0.0" y="0.0" width="912.0" height="857.0" fill="#FFFFFF" fill-opacity="1.0"/>
    <g class="ParticipantView">
        <rect x="60.0" y="70.0" width="154.0" height="61.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="137.0" y="100.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">SCIM Client</text>
    </g>
    <g class="ParticipantView">
        <rect x="234.0" y="60.0" width="180.0" height="82.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="324.0" y="92.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">SCIM</text>
        <text x="324.0" y="109.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Service Provider</text>
    </g>
    <g class="ParticipantView">
        <rect x="434.0" y="60.0" width="177.0" height="82.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="522.5" y="105.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Event Receiver</text>
    </g>
    <g class="ParticipantView">
        <rect x="631.0" y="70.0" width="221.0" height="61.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="741.5" y="100.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">ConCo-op Action Endpoint</text>
    </g>
    <g class="LifelineView">
        <line x1="136.0" y1="131.0" x2="138.0" y2="735.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineView">
        <line x1="323.0" y1="142.0" x2="325.0" y2="725.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineView">
        <line x1="522.0" y1="142.0" x2="524.0" y2="725.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineView">
        <line x1="741.0" y1="131.0" x2="743.0" y2="735.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineActivationBoxView">
        <rect x="316.0" y="213.0" width="16.0" height="160.0" fill="#FFFFFF" fill-opacity="1.0" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineActivationBoxView">
        <rect x="515.0" y="365.0" width="16.0" height="234.0" fill="#FFFFFF" fill-opacity="1.0" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="InteractionFrameView">
        <rect x="269.0" y="287.0" width="528.0" height="328.0" fill="#FFFFFF" fill-opacity="0.0"/>
        <path d="M 269.0,287.0 L 324.0,287.0 L 324.0,295.0 L 318.0,303.0 L 269.0,303.0" fill="#FFFFFF" fill-opacity="1.0" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
        <rect x="269.0" y="287.0" width="528.0" height="328.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
        <text x="296.5" y="295.0" text-anchor="middle" font-family="sans-serif" font-size="12.0" fill="#000000" fill-opacity="1.0">    loop    </text>
        <text x="344.0" y="295.0" text-anchor="start" font-family="sans-serif" font-size="12.0" fill="#000000" fill-opacity="1.0"/>
    </g>
    <g class="SignalMessageView">
        <text x="226.5" y="200.5" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[1] SCIM Operation</text>
    </g>
    <g class="SignalMessageView">
        <text x="226.5" y="245.5" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[2] SCIM Response</text>
    </g>
    <g class="SignalMessageView">
        <text x="427.5" y="336.0" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[3] Event SCIM:prov:&lt;op&gt;</text>
        <text x="427.5" y="352.0" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">id:xyz</text>
    </g>
    <g class="SignalMessageView">
        <text x="419.5" y="471.5" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[4] SCIM GET &lt;id&gt;</text>
    </g>
    <g class="SignalMessageView">
        <text x="419.5" y="517.0" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[5] Filtered</text>
        <text x="419.5" y="533.0" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">Resource Response</text>
    </g>
    <g class="SignalMessageView">
        <text x="636.5" y="578.5" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[6] Co-ordinated Action</text>
    </g>
    <g class="SignalLineView">
        <path d="M 306.0,212.0 L 316.0,217.5 L 306.0,222.0 L 306.0, 212.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="137.0" y1="217.5" x2="306.0" y2="217.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 147.0,257.0 L 137.0,262.5 L 147.0,267.0 L 147.0, 257.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="147.0" y1="262.5" x2="316.0" y2="262.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 505.0,364.0 L 515.0,369.5 L 505.0,374.0 L 505.0, 364.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="332.0" y1="369.5" x2="505.0" y2="369.5" stroke-dasharray="5.0, 3.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 334.0,483.0 L 324.0,488.5 L 334.0,493.0 L 334.0, 483.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="334.0" y1="488.5" x2="515.0" y2="488.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 505.0,545.0 L 515.0,550.5 L 505.0,555.0 L 505.0, 545.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="324.0" y1="550.5" x2="505.0" y2="550.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 732.0,590.0 L 742.0,595.5 L 732.0,600.0 L 732.0, 590.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="531.0" y1="595.5" x2="732.0" y2="595.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="NoteView">
        <rect x="429.0" y="379.0" width="188.0" height="54.0" rx="5.0" ry="5.0" fill="#FFFFFF" fill-opacity="1.0" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
        <text x="443.0" y="397.5" text-anchor="start" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Receiver may accumulate</text>
        <text x="443.0" y="414.5" text-anchor="start" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">events for periodic action.</text>
    </g>

    <!-- Generator: Sequence Diagram - v1.8.11-(198) - http://www.macsequencediagram.com -->

</svg>
--Apple-Mail=_430BFA40-08C6-4410-B701-9AF045F70A1B
Content-Disposition: attachment;
	filename=figure21.txt
Content-Type: text/plain;
	x-unix-mode=0644;
	name="figure21.txt"
Content-Transfer-Encoding: 7bit

+-----------+  +---------------+  +-----------------+  +---------------+
|SCIM Client|  | SCIM Service  |  | Event Receiver  |  | Co-op Action  |
|           |  |   Provider    |  |                 |  |   Endpoint    |
+-----------+  +---------------+  +-----------------+  +---------------+
      |                |                   |                   |
      | [1] SCIM       |                   |                   |
      |     Operation  |                   |                   |
      |--------------->|                   |                   |
      |                |                   |                   |
      | [2] SCIM       |                   |                   |
      |     Response   |                   |                   |
      |<---------------|                   |                   |
      |                |                   |                   |
      |                | [3] Event         |                   |
      |                | SCIM:prov:<op>    |                   |
      |                | id:xyz            |                   |
      |                |- - - - - - - - - >|                   |
      |                |                   |                   |
      |                |                   | Note: Receiver    |
      |                |                   | may accumulate    |
      |                |                   | events for        |
      |                |                   | periodic action.  |
      |                |                   |                   |
      |                | [4] SCIM GET <id> |                   |
      |                |<------------------|                   |
      |                |                   |                   |
      |                | [5] Filtered      |                   |
      |                |     Resource      |                   |
      |                |     Response      |                   |
      |                |------------------>|                   |
      |                |                   |                   |
      |                |                   | [6] Co-ordinated  |
      |                |                   |     Action        |
      |                |                   |------------------>|
      |                |                   |                   |
      v                v                   v                   v

--Apple-Mail=_430BFA40-08C6-4410-B701-9AF045F70A1B
Content-Disposition: attachment;
	filename=figure20.txt
Content-Type: text/plain;
	x-unix-mode=0644;
	name="figure20.txt"
Content-Transfer-Encoding: 7bit

+-------------+   +---------------------+   +------------------------+
|SCIM Client A|   |SCIM Service Provider|   |Service Provider Replica|
+-------------+   +---------------------+   +------------------------+
       |                     |                           |
       | [1] SCIM Operation  |                           |
       |-------------------->|                           |
       | [2] SCIM Response   |                           |
       |<--------------------|                           |
       |                     |                           |
       |                     | [3] Event SCIM:prov:<op>  |
       |                     |          id:xyz           |
       |                     |- - - - - - - - - - - - - >|
       |                     |                           |
       |                     |     [4] Update local node |--+
       |                     |                           |  |
       |                     |                           |<-+
       |                     |                           |
       v                     v                           v
--Apple-Mail=_430BFA40-08C6-4410-B701-9AF045F70A1B
Content-Disposition: inline;
	filename=figure20.svg
Content-Type: image/svg+xml;
	x-unix-mode=0644;
	name="figure20.svg"
Content-Transfer-Encoding: 7bit

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" viewBox="0 0 697.0 550.0">

    <!-- Generator: Sequence Diagram - v1.8.11-(198) - http://www.macsequencediagram.com -->

    <rect x="0.0" y="0.0" width="697.0" height="594.0" fill="#FFFFFF" fill-opacity="1.0"/>
    <g class="ParticipantView">
        <rect x="60.0" y="60.0" width="129.0" height="61.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="124.5" y="90.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">SCIM Client A</text>
    </g>
    <g class="ParticipantView">
        <rect x="209.0" y="50.0" width="180.0" height="82.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="299.0" y="82.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">SCIM</text>
        <text x="299.0" y="99.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Service Provider</text>
    </g>
    <g class="ParticipantView">
        <rect x="409.0" y="60.0" width="228.0" height="61.0" rx="5.0" ry="5.0" fill="#FFFFFF" stroke="#000000" stroke-width="1.0"/>
        <text x="523.0" y="90.5" text-anchor="middle" font-family="sans-serif" font-size="14.0" fill="#000000" fill-opacity="1.0">Service Provider Replica</text>
    </g>
    <g class="LifelineView">
        <line x1="124.0" y1="121.0" x2="126.0" y2="472.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineView">
        <line x1="298.0" y1="132.0" x2="300.0" y2="462.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineView">
        <line x1="522.0" y1="121.0" x2="524.0" y2="472.0" stroke-dasharray="20.0, 10.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineActivationBoxView">
        <rect x="291.0" y="193.0" width="16.0" height="115.0" fill="#FFFFFF" fill-opacity="1.0" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="LifelineActivationBoxView">
        <rect x="515.0" y="300.0" width="16.0" height="56.0" fill="#FFFFFF" fill-opacity="1.0" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalMessageView">
        <text x="208.0" y="180.5" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[1] SCIM Operation</text>
    </g>
    <g class="SignalMessageView">
        <text x="208.0" y="225.5" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[2] SCIM Response</text>
    </g>
    <g class="SignalMessageView">
        <text x="415.0" y="271.0" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[3] Event SCIM:prov:&lt;op&gt;</text>
        <text x="415.0" y="287.0" text-anchor="middle" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">id:xyz</text>
    </g>
    <g class="SignalMessageView">
        <text x="511.0" y="332.5" text-anchor="end" font-family="sans-serif" font-size="13.0" fill="#000000" fill-opacity="1.0">[4] Update local node</text>
    </g>
    <g class="SignalLineView">
        <path d="M 281.0,192.0 L 291.0,197.5 L 281.0,202.0 L 281.0, 192.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="125.0" y1="197.5" x2="281.0" y2="197.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 135.0,237.0 L 125.0,242.5 L 135.0,247.0 L 135.0, 237.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="135.0" y1="242.5" x2="291.0" y2="242.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 505.0,299.0 L 515.0,304.5 L 505.0,309.0 L 505.0, 299.0" fill="#000000" fill-opacity="1.0"/>

        <line x1="307.0" y1="304.5" x2="505.0" y2="304.5" stroke-dasharray="5.0, 3.0" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>
    <g class="SignalLineView">
        <path d="M 541.0,342.0 L 530.5,346.5 L 541.0,352.0 L 541.0,342.0" fill="#000000" fill-opacity="1.0"/>
        <line x1="531.5" y1="324.5" x2="570.5" y2="324.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
        <line x1="570.5" y1="346.5" x2="541.0" y2="346.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
        <path d="M 570.5,324.5 Q 580.5,324.5 580.5, 334.5 L 580.5 336.5 Q 580.5,346.5 570.5,346.5" fill="none" stroke="#000000" stroke-opacity="1.0" stroke-width="1.0"/>
    </g>

    <!-- Generator: Sequence Diagram - v1.8.11-(198) - http://www.macsequencediagram.com -->

</svg>
--Apple-Mail=_430BFA40-08C6-4410-B701-9AF045F70A1B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

>>=20
>>=20
>> 17) <!-- [rfced] Please review each artwork element and let us know =
if any should
>> be marked as sourcecode (or another element) instead.
>>=20
>> Note that we updated <artwork> to <sourcecode> in several sections. =
Please=20
>> confirm that this is correct.
>>=20
>> In addition, please consider whether the "type" attribute of any =
sourcecode
>> element should be set and/or has been set correctly.
>>=20
>> The current list of preferred values for "type" is available at
>> https://www.rfc-editor.org/materials/sourcecode-types.txt. 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>
>>=20
> <PH>  =20
>=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
>=20
> Figure 20 and 21 are artwork AFAIK.
>=20
>>=20
>> 18) <!-- [rfced] Terminology
>>=20
>> a) Throughout the text, the following terminology appears to be used=20=

>> inconsistently. Please review these occurrences and let us know =
if/how they
>> may be made consistent. =20
>>=20
>>  Asynchronous SCIM Request vs. asynchronous SCIM request=20
>>   (also Asynchronous SCIM Request capability)
>>=20
>>  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
>>=20
>>  Event Feed vs. event feed
>>=20
>>  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".]
>>=20
>>  Event Receiver vs. receiver
>>    [Note: Do any of the lowercase forms refer to an "Event =
Receiver=E2=80=9D?]
>>=20
> <PH>  Thanks. Good catch.  I was attempting to follow the practice of =
terminology e.g. SHOULD vs should.
>=20
> 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. =20
>=20
> E.g. The Event Feed vs passing events to an event feed.
>=20
> Thoughts?  I am ok proper casing everything if you prefer.
>=20
>> b) How may we update these terms for consistency?
>>=20
>>  Event Feed (or event feed) vs. Feed Event vs. Feed Management event
>>=20
>>  HTTP Service Endpoint vs. HTTP endpoint
>>    [Note: Also consider "Event Publisher endpoint=E2=80=9D.]
>>=20
> <PH> Drop service and just use HTTP endpoint
>=20
>>  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)
>>=20
> <PH> Please match
>=20
>>  JSON Web Token vs. JSON token
>>=20
> <PH> Use JSON Web Token
>=20
>> 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=20=

>> do you prefer for these terms to be uppercase throughout the =
document?
>>=20
>>  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)
>>=20
> <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.
>=20
> 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.
>>=20
>>  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
>=20
> ok
>=20
>>=20
>> e) For "Co-ordinated Provisioning", may we remove the hyphen=20
>> 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=20
>> 'coordination' in this document.)
>>=20
>=20
> yes
>=20
>> f) We note the following variance:
>> Co-ordinated Provisioning (CP) vs. Co-operative Provisioning (CP)
>>=20
>> May the 2 instances of "Co-operative Provisioning" be updated to=20
>> "Coordinated Provisioning" (note: "operative" to "ordinated")?=20
>> In other words, we suggest:
>>=20
>> 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.=20
>>=20
>> Section 2.4
>>   These events are used in both Domain-Based Replication (DBR) and=20
>>   Coordinated Provisioning (CP) mode.=20
>> -->
>=20
> <PH> ok
>>=20
>>=20
>> 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.
>>=20
>>  JSON Web Signature (JWS)
>>  Globally Unique Identifier (GUID)
>> =E2=80=94>
>>=20
> <PH> thanks
>>=20
>> 20) <!-- [rfced] Please review the "Inclusive Language" portion of =
the online=20
>> Style Guide =
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>> and let us know if any changes are needed.  Updates of this nature =
typically
>> result in more precise language, which is helpful for readers.
>>=20
>> Note that our script did not flag any words in particular, but this =
should=20
>> still be reviewed as a best practice.
>> -->
>=20
> <PH> I am not aware of any issues according to the examples in the =
links provided.
>>=20
>>=20
>> Thank you.
>>=20
>> Karen Moore and Alice Russo
>> RFC Production Center
>>=20
>>=20
>> On May 1, 2026, rfc-editor@rfc-editor.org wrote:
>>=20
>> *****IMPORTANT*****
>>=20
>> Updated 2026/05/01
>>=20
>> RFC Author(s):
>> --------------
>>=20
>> Instructions for Completing AUTH48
>>=20
>> Your document has now entered AUTH48.  Once it has been reviewed and=20=

>> 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=20
>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>=20
>> You and you coauthors are responsible for engaging other parties=20
>> (e.g., Contributors or Working Group) as necessary before providing=20=

>> your approval.
>>=20
>> Planning your review=20
>> ---------------------
>>=20
>> Please review the following aspects of your document:
>>=20
>> *  RFC Editor questions
>>=20
>>  Please review and resolve any questions raised by the RFC Editor=20
>>  that have been included in the XML file as comments marked as=20
>>  follows:
>>=20
>>  <!-- [rfced] ... -->
>>=20
>>  These questions will also be sent in a subsequent email.
>>=20
>> *  Changes submitted by coauthors=20
>>=20
>>  Please ensure that you review any changes submitted by your=20
>>  coauthors.  We assume that if you do not speak up that you=20
>>  agree to changes submitted by your coauthors.
>>=20
>> *  Content=20
>>=20
>>  Please review the full content of the document, as this cannot=20
>>  change once the RFC is published.  Please pay particular attention =
to:
>>  - IANA considerations updates (if applicable)
>>  - contact information
>>  - references
>>=20
>> *  Copyright notices and legends
>>=20
>>  Please review the copyright notice and legends as defined in
>>  RFC 5378 and the Trust Legal Provisions=20
>>  (TLP =E2=80=93 https://trustee.ietf.org/license-info).
>>=20
>> *  Semantic markup
>>=20
>>  Please review the markup in the XML file to ensure that elements of =20=

>>  content are correctly tagged.  For example, ensure that <sourcecode>=20=

>>  and <artwork> are set correctly.  See details at=20
>>  <https://authors.ietf.org/rfcxml-vocabulary>.
>>=20
>> *  Formatted output
>>=20
>>  Please review the PDF, HTML, and TXT files to ensure that the=20
>>  formatted output, as generated from the markup in the XML file, is=20=

>>  reasonable.  Please note that the TXT will have formatting=20
>>  limitations compared to the PDF and HTML.
>>=20
>>=20
>> Submitting changes
>> ------------------
>>=20
>> To submit changes, please reply to this email using =E2=80=98REPLY =
ALL=E2=80=99 as all=20
>> the parties CCed on this message need to see your changes. The =
parties=20
>> include:
>>=20
>>  *  your coauthors
>>=20
>>  *  rfc-editor@rfc-editor.org (the RPC team)
>>=20
>>  *  other document participants, depending on the stream (e.g.,=20
>>     IETF Stream participants are your working group chairs, the=20
>>     responsible ADs, and the document shepherd).
>>=20
>>  *  auth48archive@rfc-editor.org, which is a new archival mailing =
list=20
>>     to preserve AUTH48 conversations; it is not an active discussion=20=

>>     list:
>>=20
>>    *  More info:
>>       =
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P=
8O4Zc
>>=20
>>    *  The archive itself:
>>       https://mailarchive.ietf.org/arch/browse/auth48archive/
>>=20
>>    *  Note: If only absolutely necessary, you may temporarily opt out=20=

>>       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=20=

>>       have dropped the address. When the discussion is concluded,=20
>>       auth48archive@rfc-editor.org will be re-added to the CC list =
and=20
>>       its addition will be noted at the top of the message.=20
>>=20
>> You may submit your changes in one of two ways:
>>=20
>> An update to the provided XML file
>> =E2=80=94 OR =E2=80=94
>> An explicit list of changes in this format
>>=20
>> Section # (or indicate Global)
>>=20
>> OLD:
>> old text
>>=20
>> NEW:
>> new text
>>=20
>> You do not need to reply with both an updated XML file and an =
explicit=20
>> list of changes, as either form is sufficient.
>>=20
>> 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,=20
>> and technical changes.  Information about stream managers can be =
found in=20
>> the FAQ.  Editorial changes do not require approval from a stream =
manager.
>>=20
>>=20
>> Approving for publication
>> --------------------------
>>=20
>> 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.
>>=20
>>=20
>> Files=20
>> -----
>>=20
>> The files are available here:
>>  https://www.rfc-editor.org/authors/rfc9967.xml
>>  https://www.rfc-editor.org/authors/rfc9967.html
>>  https://www.rfc-editor.org/authors/rfc9967.pdf
>>  https://www.rfc-editor.org/authors/rfc9967.txt
>>=20
>> Diff file of the text:
>>  https://www.rfc-editor.org/authors/rfc9967-diff.html
>>  https://www.rfc-editor.org/authors/rfc9967-rfcdiff.html (side by =
side)
>>=20
>> Diff of the XML:=20
>>  https://www.rfc-editor.org/authors/rfc9967-xmldiff1.html
>>=20
>>=20
>> Tracking progress
>> -----------------
>>=20
>> The details of the AUTH48 status of your document are here:
>>  https://www.rfc-editor.org/auth48/rfc9967
>>=20
>> Please let us know if you have any questions. =20
>>=20
>> Thank you for your cooperation,
>>=20
>> RFC Editor
>>=20
>> --------------------------------------
>> RFC9967 (draft-ietf-scim-events-16)
>>=20
>> 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
>=20


--Apple-Mail=_430BFA40-08C6-4410-B701-9AF045F70A1B--