[auth48] Re: questions - Re: AUTH48: RFC-to-be 9967 <draft-ietf-scim-events-16> for your review

[Phillip Hunt <[e-mail]>]

We also might want to change Jennifer’s email as it is bouncing. 

Phil
[e-mail]






> On May 5, 2026, at 1:49 PM, Karen Moore <[e-mail]> wrote:
> 
> Hi Phil,
> 
> Thank you for your reply.  We have updated our files accordingly. Note that we have some additional questions.
> 
> 1)  Please clarify if the column header in Table 1 (Section 7.4) should be "Event URI”, "Schema URI”, or other.  If you feel that further explanation is needed, you can add text to the Definitions section as you suggest or a note under Table 1.
> 
>> <!-- [rfced] In Section 7.4, the header of the first column in
>> Table 1 is "Event URI", but it is "Schema URI" in the
>> "SCIM Event URIs" registry <https://www.iana.org/assignments/scim/>. 
>> Do you prefer to use "Event URI" or "Schema URI"?  Note that we 
>> will communicate any changes to the registry to IANA. 
>> 
>> <PH> These are actually different uses. EventURIs are used in JWT not
>> in SCIM protocol itself.  SCIM “Schemas” do appear in some SCIM Events
>> (e.g. urn:ietf:params:scim:event:prov:create:full has a “data” element
>> that contains schemas.  (See Figure 4)
>> 
>> Not sure if we need better explanation somewhere such as definitions?
>> -->
> 
> 2) We have not made any updates yet to the case of the terminology in question. We suggest going with lowercase to match RFCs 7643 and 7644; however, this is author preference. Please discuss with your coauthors and confirm if you would like to go with uppercase or lowercase and we will make the updates.
> 
> 3) Thank you for providing the updated SVG figures. Regarding Figure 21, we note that the SVG version in the html file contains a loop but the ascii-art version in the txt file does not. Is this variance okay, or should it be described in the running text or noted under the figure?
> 
> Also, in the box in the upper right corner, should "Co-op Action Endpoint” be “Coord. Action Endpoint”?
> 
> —Files— 
> 
> Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC.
> 
> Please contact us with any further updates or with your approval of the document in its current form.  We will await approvals from each author prior to moving forward in the publication process.
> 
> Updated XML file:
> https://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 PM, Phillip Hunt <[e-mail]> wrote:
>> 
>> 
>> Thank you very much for the feedback!
>> 
>> My answers are included below.  As I agree with only some subtle changes, I will let you update the rfc editor version rather than producing draft 17.
>> 
>> Please find attached 4 files for the 2 figures.  I have attempted to make them align.  The contents should be paste-able directly in the document xml
>> 
>> Let me know if there is anything else.
>> 
>> —> co-authors, please check as well per the instructions in the previous email.
>> 
>> Phil
>> [e-mail]
>> 
>> 
>> 
>> 
>> 
>> 
>>> On May 1, 2026, at 3:17 PM, [e-mail] wrote:
>>> 
>>> Authors,
>>> 
>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
>>> 
>>> 1) <!--[rfced] Please note that the title of the document has
>>> been updated as follows.  Abbreviations have been expanded per
>>> Section 3.6 of RFC 7322 ("RFC Style Guide"), and the short title
>>> that spans the header of the PDF file has been updated as shown
>>> below. Please review.
>>> 
>>> Original (document title):
>>>  SCIM Profile for Security Event Tokens
>>> 
>>> Current: 
>>>  System for Cross-domain Identity Management (SCIM) Profile for 
>>>  Security Event Tokens (SETs)
>>> 
>>> ...
>>> Original (short title):
>>>  draft-ietf-scim-events-16
>>> 
>>> Current:
>>>  SCIM Profile for SETs
>>> -->   
>>> 
>> <PH> oik
>>> 
>>> 2) <!--[rfced] Abstract: FYI, we added the RFC number of the SET specification
>>> (RFC 8417) so that the text is more specific. Please let us know if you
>>> prefer otherwise.
>>> 
>>> Original:
>>>  This specification defines a set of System for Cross-domain Identity
>>>  Management (SCIM) Security Events using the Security Event Token
>>>  Specification to enable the asynchronous exchange of messages between
>>>  SCIM Service Providers and receivers.
>>> 
>>> Current:
>>>  This specification defines a set of System for Cross-domain Identity
>>>  Management (SCIM) Security Events using the Security Event Token
>>>  (SET) specification (RFC 8417) to enable the asynchronous exchange of
>>>  messages between SCIM Service Providers and receivers.
>>> -->
>> 
>> <PH>  No opinions.  I thought RFC numbers not allowed in abstracts.  :)
>>> 
>>> 
>>> 3) <!--[rfced] The term "SCIM Protocol Client" does not appear in RFC 7644
>>> or other RFCs, so may we update it to "SCIM client" (2 instances), which
>>> is used in RFC 7644?
>>> 
>>> Original:
>>>  This specification defines the use of the HTTP Header "Prefer:
>>>  respond-async" [RFC7240] to allow a SCIM Protocol Client [RFC7644] to
>>>  request an asynchronous response (see Section 2.5.1.1).
>>> 
>>>  Using the HTTP protocol, a SCIM Protocol Client issues commands...
>>> 
>>> Perhaps:
>>>  This specification defines the use of the HTTP Header "Prefer:
>>>  respond-async" [RFC7240] to allow a SCIM client [RFC7644] to
>>>  request an asynchronous response (see Section 2.5.1.1).
>>> 
>>> Using the HTTP protocol, a SCIM client issues commands...
>>> —>
>>> 
>> <PH> ok
>>> 
>>> 4) <!-- [rfced] We note that RFC 8935 does not use the terms "SET Push
>>> Transfer" or "Push Transfer"; it does use "push-based SET
>>> delivery". RFC 8936 does not use "SET Poll-Based Transfer" or
>>> "Poll-Based Transfer"; it does use "poll-based SET delivery". Is
>>> an update needed for consistency?
>>> 
>>> Original:
>>>  In the case of SET Push Transfer [RFC8935], the Event Receiver is
>>>  an HTTP Service Endpoint that receives requests. In the case of SET
>>>  Poll-Based Transfer [RFC8936], the receiver is an HTTP client that
>>>  initiates HTTP request to an Event Publisher endpoint.
>>> 
>>> Perhaps:
>>>  In the case of push-based SET delivery [RFC8935], the Event Receiver
>>>  is an HTTP Service Endpoint that receives requests. In the case of
>>>  poll-based SET delivery [RFC8936], the receiver is an HTTP client
>>>  that initiates HTTP requests to an Event Publisher endpoint.
>>> -->
>> <PH> ok
>>> 
>>> 
>>> 5) <!--[rfced] In Section 3.1, we replaced "SET" with "Security Event
>>> Token (SET)" for consistency with how the other terms are
>>> displayed in the list. Please let us know of any objection.
>>> 
>>> Original:
>>>  SET:  Abbreviation for "Security Event Token" as defined in [RFC8417]
>>> 
>>> Current:
>>>  Security Event Token (SET):  As defined in [RFC8417].
>>> -->
>>> 
>> <PH> ok
>>> 
>>> 
>>> 6) <!--[rfced] In Sections 2.1, 2.2, and 4, may we add colons to the list of
>>> terms/attributes that are defined, or do you prefer no colons?
>>> 
>>> One example
>>> 
>>> Original:
>>>  uri
>>>     The SCIM relative path for the resource which usually consists of
>>>     the resource type endpoint plus the resource "id" ...
>>> 
>>> Perhaps
>>>  uri:
>>>     The SCIM relative path for the resource that usually consists of
>>>     the resource type endpoint plus the resource "id" ...
>>> -->
>> <PH> no objection
>>> 
>>> 
>>> 7) <!--[rfced] Section 3.1 of [RFC7643] uses "id" rather than "Id". Is an
>>> update needed in this sentence for consistency?
>>> 
>>> Current:
>>> id
>>>  The SCIM Id attribute (defined in Section 3.1 of [RFC7643]) MAY be
>>>  used for backwards compatibility reasons in addition to the "uri"
>>>  claim.
>>> 
>>> Perhaps:
>>> id
>>>  The SCIM "id" attribute (defined in Section 3.1 of [RFC7643]) MAY be
>>>  used for backwards compatibility reasons in addition to the "uri"
>>>  claim.
>>> -->
>> <PH> ok
>>> 
>>> 
>>> 8) <!-- [rfced] Section 4 of [RFC7643] uses "userName" rather than
>>> "username" when referring to the attribute. Should this text
>>> be updated accordingly?
>>> 
>>> Section 2.1
>>> Current:
>>>  For example, attributes such as "emails" or "username" (defined in
>>>  Section 4 of [RFC7643]) are unique with in a SCIM Service Provider. 
>>> 
>>> Perhaps:
>>>  For example, attributes such as "emails" or "userName" (defined in
>>>  Section 4 of [RFC7643]) are unique with in a SCIM Service Provider. 
>>> 
>>> ...
>>> Section 2.2
>>> Current:
>>>  For example: "attributes": ["username","emails","name.familyName"]
>>> 
>>> Perhaps:
>>>  For example: "attributes": ["userName","emails","name.familyName"]
>>> -->
>> 
>> <PH>  attributes in JWT and SCIM are case insensitive. But the case as was written was consistent with RFC7643 (which is userName).   I have no objections either way.
>>> 
>>> 
>>> 9) <!--[rfced] FYI, in Section 2.2 about "attributes", please review:
>>> - removed the extraneous '>' in '"path">'. Seems it was a typo. 
>>> - removed the line break after "For example:". If you prefer that
>>> the example be in a sourcecode element, please let us know.
>>> 
>>> Original:
>>>  Names of modified attributes SHOULD conform to the ABNF syntax rule
>>>  for "path"> (Section 3.5.2 of [RFC7644]). 
>>>  For example:
>>>  "attributes": ["username","emails","name.familyName"]
>>> 
>>> Current:
>>>  Names of modified attributes SHOULD conform to the ABNF syntax
>>>  rule for "path" (see Section 3.5.2 of [RFC7644] and [RFC5234]). 
>>>  For example: "attributes": ["username","emails","name.familyName"].
>>> -->
>>> 
>>> 
>> <PH> thanks. correct.
>> 
>>> 10) <!--[rfced] Should the middle initial for Barbara Jensen III be "J."
>>> (with a period) in Figure 12, or is the current text correct?
>>> 
>>> Current:
>>> "formatted":"Ms. Barbara J Jensen III"
>>> 
>>> Perhaps:
>>> "formatted":"Ms. Barbara J. Jensen III"  
>>> —
>>> 
>> <PH> Just an example, doesn’t matter.  The example in Figure 2 of RFC7643 has no period.
>>> 
>>> 11) <!--[rfced] We note that Figure 13 is the only figure without a
>>> title. Would you like to add one? If so, please provide the
>>> desired text.
>>> —>
>>> 
>> <PH> How about "Async SCIM Request With Prefer Header"
>>> 
>>> 12) <!--[rfced] The following sentence does not parse. Please let us know
>>> how we may update for clarity.
>>> 
>>> Original:
>>>   Providing the exact date of each membership change is not critical
>>>   but instead that the information content remains intact.
>>> -->
>> 
>> <PH> Proposed:
>> 
>> If providing the exact date of each membership change is not critical, consider
>> using a PATCH to aggregate multiple membership changes into a single event.
>> </PH>
>>> 
>>> 
>>> 13) <!-- [rfced] In Section 7.4, the header of the first column in
>>> Table 1 is "Event URI", but it is "Schema URI" in the
>>> "SCIM Event URIs" registry <https://www.iana.org/assignments/scim/>. 
>>> Do you prefer to use "Event URI" or "Schema URI"?  Note that we 
>>> will communicate any changes to the registry to IANA. 
>>> -->  
>> <PH>
>> These are actually different uses. EventURIs are used in JWT not in SCIM protocol itself.  SCIM “Schemas” do appear in some SCIM Events (e.g. urn:ietf:params:scim:event:prov:create:full has a “data” element that contains schemas.  (See Figure 4)
>> 
>> Not sure if we need better explanation somewhere such as definitions?
>> 
>>> 
>>> 
>>> 14) <!-- [rfced] The RFC Production Center has been advised that "ASCII"
>>> and not "US-ASCII" should be used.  May we change instances of
>>> "US-ASCII" in this document to "ASCII" as shown below?
>>> 
>>> Original:
>>> name   A US-ASCII string that conforms to URN syntax requirements (see
>>>        [RFC8141]) and defines a descriptive event name (e.g.,
>>>        "create").
>>> 
>>> other  An optional US-ASCII string that conforms to URN syntax
>>>        requirements (see [RFC8141]) and serves as an additional sub-
>>>        category or qualifier. 
>>> 
>>> Perhaps:
>>> name   An ASCII string that conforms to URN syntax requirements (see
>>>        [RFC8141]) and defines a descriptive event name (e.g.,
>>>        "create").
>>> 
>>> other  An optional ASCII string that conforms to URN syntax
>>>        requirements (see [RFC8141]) and serves as an additional sub-
>>>        category or qualifier. 
>>> —>
>>> 
>> <PH>  RFC8141 says ASCII so this change ok
>>> 
>>> 15) <!--[rfced] The SVG and ASCII artworks of Figure 20 are inconsistent
>>> with each other. Please provide updated artwork for this figure.
>>> 
>>> (See https://www.rfc-editor.org/authors/rfc9967.html#figure-20
>>> vs. https://www.rfc-editor.org/authors/rfc9967.txt)
>>> 
>>> 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://www.rfc-editor.org/authors/rfc9967.html#figure-21
>>> vs. https://www.rfc-editor.org/authors/rfc9967.txt)
>>> 
>>> Examples:
>>> 
>>> a) Inconsistent labels and positioning of the terms in the html vs. txt outputs: 
>>> 
>>> SCIM Client vs. SCIM Clnt (CA)
>>> SCIM Service Provider vs. SCIM Service Provider (SP)
>>> Client A Co-op Receiver vs. Client A Co-op Receiver (ER)
>>> Co-op Action Endpoint vs. Co-op Action Endpoint(LEP)
>>> [1] SCIM Operation vs. "SCIM Operation"
>>> [2] SCIM Response vs. "SCIM Response"
>>> 
>>> [3] Event SCIM:prov:<op> id=xyz vs. "Event SCIM:prov:<op>, id=xyz"
>>>    [Note: There is a dotted line underneath this term in the html output 
>>>    but no dotted line in the txt output.]
>>> 
>>> Receiver may accumulate events for periodic action. vs.
>>>  Note: Receiver may accumulate events for periodic action 
>>>    [Note: This text appears in a box in the html output and without a
>>>    box in the txt output.]
>>> 
>>> [4] SCIM GET <id> vs. "SCIM GET <id>"
>>>    [Note: this term appears over the line in the html output but 
>>>    next to the line in the txt output.]
>>> 
>>> [5] Filtered Resource Response vs. "Filtered Resource Resp."
>>>    [Note: This term appears over the line in the html output but 
>>>    next to the line in the txt output.]
>>> 
>>> [6] Co-ordinated Action vs. "Co-ord Action"
>>>     [Note: This term appears over the line in the html output but 
>>>     under the line in the txt output.]
>>> 
>>> b) "loop" (and the box it appears in) is present in the html output but is 
>>> missing in the txt output.
>>> -->
>>> 
>> <PH>  I have made changes as follows:
>>  Figure 20:                                                                                                                                                                                                                                                                                                                                                                                                                                             
>>  - In-doc ASCII: replaced flow-chart style with sequence-diagram version from figure20.txt (max 70 chars, all under 72)
>>  - In-doc SVG: "Client A" → "SCIM Client A" to match the standalone SVG and ASCII                                                                                                                                                                                                                                                                                                                                                                       
>>  - Now all four sources (standalone SVG, standalone TXT, in-doc SVG, in-doc ASCII) use identical participant names and the same sequence-diagram visual style                                                                                                                                                                                                                                                                                         
>>                                                                                                                                                                                                                                                                                                                                                                                                                                                           Figure 21 (from previous turn):                                                                                                                                                                                                                                                                                                                                                                                                                        
>>  - All four sources use "SCIM Client" / "SCIM Service Provider" / "Event Receiver" / "Co-op Action Endpoint" in matching sequence-diagram style      
>> 
>> For you edit see the files attached and replace in the XML sections as appropriate.

>>> 
>>> 
>>> 17) <!-- [rfced] Please review each artwork element and let us know if any should
>>> be marked as sourcecode (or another element) instead.
>>> 
>>> Note that we updated <artwork> to <sourcecode> in several sections. Please 
>>> confirm that this is correct.
>>> 
>>> In addition, please consider whether the "type" attribute of any sourcecode
>>> element should be set and/or has been set correctly.
>>> 
>>> The current list of preferred values for "type" is available at
>>> https://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.
>>> —>
>>> 
>> <PH>   
>> 
>> All of the figures with JSON in them should be changed to <sourcecode type=“json”>
>> - Figures 1 through 19
>> 
>> Figure 20 and 21 are artwork AFAIK.
>> 
>>> 
>>> 18) <!-- [rfced] Terminology
>>> 
>>> a) Throughout the text, the following terminology appears to be used 
>>> inconsistently. Please review these occurrences and let us know if/how they
>>> may be made consistent.  
>>> 
>>> Asynchronous SCIM Request vs. asynchronous SCIM request 
>>>  (also Asynchronous SCIM Request capability)
>>> 
>>> Asynchronous Request completion vs.
>>> asynchronous request completion vs.
>>> Asynchronous Request Completion Event vs.
>>> Asynchronous Request Completion event vs.
>>> asynchronous request completion event vs.
>>> Asynchronous Event completion event vs.
>>> Asynchronous Completion event
>>> 
>>> Event Feed vs. event feed
>>> 
>>> Event Payload vs. event payload
>>>  [Note: RFC 8417 uses the lowercase forms for "event feed" and
>>>  "event payload". Please also consider if the case should be updated
>>>  for "Event Publisher", "Event Stream", and "Event Receiver".]
>>> 
>>> Event Receiver vs. receiver
>>>   [Note: Do any of the lowercase forms refer to an "Event Receiver”?]
>>> 
>> <PH>  Thanks. Good catch.  I was attempting to follow the practice of terminology e.g. SHOULD vs should.
>> 
>> Lower case is appropriate when using it in general langauge.  When referring to the defined thing or in heading I believe proper case is appropriate.  
>> 
>> E.g. The Event Feed vs passing events to an event feed.
>> 
>> Thoughts?  I am ok proper casing everything if you prefer.
>> 
>>> b) How may we update these terms for consistency?
>>> 
>>> Event Feed (or event feed) vs. Feed Event vs. Feed Management event
>>> 
>>> HTTP Service Endpoint vs. HTTP endpoint
>>>   [Note: Also consider "Event Publisher endpoint”.]
>>> 
>> <PH> Drop service and just use HTTP endpoint
>> 
>>> HTTP Status 202 (Accepted) vs.
>>> HTTP Status 202 Accepted vs.
>>> HTTP 202 Accepted
>>>   Note: Perhaps (to match usage in RFC 7644):
>>>     HTTP status code 202 (Accepted)
>>> 
>> <PH> Please match
>> 
>>> JSON Web Token vs. JSON token
>>> 
>> <PH> Use JSON Web Token
>> 
>>> c) We note that some terms that appear as uppercase (or a mix of
>>> uppercase and lowercase) in this document appear as lowercase in the
>>> referenced RFCs. Would you like to update the terms below to reflect
>>> the forms on the right for consistency with the referenced RFCs, or 
>>> do you prefer for these terms to be uppercase throughout the document?
>>> 
>>> SCIM Client -> SCIM client (per RFCs 7643 and 7644)
>>> SCIM Complex attribute -> SCIM complex attribute (per RFC 7644)
>>> SCIM Protocol -> SCIM protocol (per RFC 7644)
>>> SCIM Resource -> SCIM resource (per RFCs 7643 and 7644)
>>> SCIM Response -> SCIM response (per RFC 7644)
>>> SCIM Schema -> SCIM schema (per RFC 7643)
>>> SCIM Service Provider -> SCIM service provider (per RFCs 7643, 7644, and 9865)
>>> 
>> <PH> I believe this is an artificat of changing IETF styles over time. During the writing of 7644 they didn’t want capitalization.
>> 
>> Similar to above (regarding is it a term or plain language).  I am ok with going either with proper case “things” or the “SCIM client” approach defpending on your current style guide.
>>> d) FYI: We made the following updates for consistency. Please let us
>>> know if any further updates are needed.
>>> 
>>> Bulk request -> bulk request (per RFC 7644)
>>> Etag -> ETag (per RFC 7644)
>>> HTTP Client -> HTTP client (per RFC 7644)
>>> HTTP Header -> HTTP header (per RFCs 7240 and 7644)
>>> SCIM event -> SCIM Event
>> 
>> ok
>> 
>>> 
>>> e) For "Co-ordinated Provisioning", may we remove the hyphen 
>>> to match common spelling of "coordinated"?
>>> Or, is there some special meaning when using the hyphen?
>>> (Depending on your reply, we will update the various forms of 
>>> 'coordination' in this document.)
>>> 
>> 
>> yes
>> 
>>> f) We note the following variance:
>>> Co-ordinated Provisioning (CP) vs. Co-operative Provisioning (CP)
>>> 
>>> May the 2 instances of "Co-operative Provisioning" be updated to 
>>> "Coordinated Provisioning" (note: "operative" to "ordinated")? 
>>> In other words, we suggest:
>>> 
>>> Section 2.3
>>>  This section defines events related to changes in the content of an
>>>  event feed such as SCIM Resources that are being added or removed
>>>  from an event feed or events used in Coordinated Provisioning
>>>  scenarios where only a subset of entities are shared across an Event
>>>  Feed. 
>>> 
>>> Section 2.4
>>>  These events are used in both Domain-Based Replication (DBR) and 
>>>  Coordinated Provisioning (CP) mode. 
>>> -->
>> 
>> <PH> ok
>>> 
>>> 
>>> 19) <!-- [rfced] FYI - We have added expansions for abbreviations upon first use
>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review these and each
>>> expansion in the document carefully to ensure correctness.
>>> 
>>> JSON Web Signature (JWS)
>>> Globally Unique Identifier (GUID)
>>> —>
>>> 
>> <PH> thanks
>>> 
>>> 20) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
>>> Style Guide <https://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.
>>> 
>>> 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, [e-mail] wrote:
>>> 
>>> *****IMPORTANT*****
>>> 
>>> Updated 2026/05/01
>>> 
>>> RFC Author(s):
>>> --------------
>>> 
>>> Instructions for Completing AUTH48
>>> 
>>> Your document has now entered AUTH48.  Once it has been reviewed and 
>>> approved by you and all coauthors, it will be published as an RFC.  
>>> If an author is no longer available, there are several remedies 
>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/)
>>> 
>>> You and you coauthors are responsible for engaging other parties 
>>> (e.g., Contributors or Working Group) as necessary before providing 
>>> your approval.
>>> 
>>> Planning your review 
>>> ---------------------
>>> 
>>> Please review the following aspects of your document:
>>> 
>>> *  RFC Editor questions
>>> 
>>> Please review and resolve any questions raised by the RFC Editor 
>>> that have been included in the XML file as comments marked as 
>>> follows:
>>> 
>>> <!-- [rfced] ... -->
>>> 
>>> These questions will also be sent in a subsequent email.
>>> 
>>> *  Changes submitted by coauthors 
>>> 
>>> Please ensure that you review any changes submitted by your 
>>> coauthors.  We assume that if you do not speak up that you 
>>> agree to changes submitted by your coauthors.
>>> 
>>> *  Content 
>>> 
>>> Please review the full content of the document, as this cannot 
>>> change once the RFC is published.  Please pay particular attention to:
>>> - IANA considerations updates (if applicable)
>>> - contact information
>>> - references
>>> 
>>> *  Copyright notices and legends
>>> 
>>> Please review the copyright notice and legends as defined in
>>> RFC 5378 and the Trust Legal Provisions 
>>> (TLP – https://trustee.ietf.org/license-info)
>>> 
>>> *  Semantic markup
>>> 
>>> Please review the markup in the XML file to ensure that elements of  
>>> content are correctly tagged.  For example, ensure that <sourcecode> 
>>> and <artwork> are set correctly.  See details at 
>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>> 
>>> *  Formatted output
>>> 
>>> Please review the PDF, HTML, and TXT files to ensure that the 
>>> formatted output, as generated from the markup in the XML file, is 
>>> reasonable.  Please note that the TXT will have formatting 
>>> limitations compared to the PDF and HTML.
>>> 
>>> 
>>> Submitting changes
>>> ------------------
>>> 
>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
>>> the parties CCed on this message need to see your changes. The parties 
>>> include:
>>> 
>>> *  your coauthors
>>> 
>>> *  [e-mail] (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).
>>> 
>>> *  [e-mail], which is a new archival mailing list 
>>>    to preserve AUTH48 conversations; it is not an active discussion 
>>>    list:
>>> 
>>>   *  More info:
>>>      https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>> 
>>>   *  The archive itself:
>>>      https://mailarchive.ietf.org/arch/browse/auth48archive/
>>> 
>>>   *  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, 
>>>      [e-mail] will be re-added to the CC list and 
>>>      its addition will be noted at the top of the message. 
>>> 
>>> You may submit your changes in one of two ways:
>>> 
>>> An update to the provided XML file
>>> — OR —
>>> An explicit list of changes in this format
>>> 
>>> Section # (or indicate Global)
>>> 
>>> OLD:
>>> old text
>>> 
>>> NEW:
>>> new text
>>> 
>>> You do not need to reply with both an updated XML file and an explicit 
>>> list of changes, as either form is sufficient.
>>> 
>>> We will ask a stream manager to review and approve any changes that seem
>>> beyond editorial in nature, e.g., addition of new text, deletion of text, 
>>> and technical changes.  Information about stream managers can be found in 
>>> the FAQ.  Editorial changes do not require approval from a stream manager.
>>> 
>>> 
>>> Approving for publication
>>> --------------------------
>>> 
>>> To approve your RFC for publication, please reply to this email stating
>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>>> as all the parties CCed on this message need to see your approval.
>>> 
>>> 
>>> Files 
>>> -----
>>> 
>>> The files are available here:
>>> https://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
>>> 
>>> 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)
>>> 
>>> Diff of the XML: 
>>> https://www.rfc-editor.org/authors/rfc9967-xmldiff1.html
>>> 
>>> 
>>> Tracking progress
>>> -----------------
>>> 
>>> The details of the AUTH48 status of your document are here:
>>> https://www.rfc-editor.org/auth48/rfc9967
>>> 
>>> Please let us know if you have any questions.  
>>> 
>>> Thank you for your cooperation,
>>> 
>>> RFC Editor
>>> 
>>> --------------------------------------
>>> RFC9967 (draft-ietf-scim-events-16)
>>> 
>>> Title            : SCIM Profile for Security Event Tokens
>>> Author(s)        : P. Hunt, Ed., N. Cam-Winget, M. Kiser, J. Schreiber
>>> WG Chair(s)      : Nancy Cam-Winget
>>> Area Director(s) : Deb Cooley, Christopher Inacio
>>> 
>> 
>