Hi Anjali, Thank you for your review. We have noted your approval on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9865>.
We will wait to hear from your coauthors before continuing with the publication process. Thank you, Sandy Ginoza RFC Production Center > On Sep 30, 2025, at 4:24 AM, Sehgal, Anjali <[email protected]> wrote: > > Hi Sandy, > > Looks good. No further updates needed. > > Thanks > Anjali > > On 2025-09-26, 11:25 AM, "Sandy Ginoza" <[email protected] > <mailto:[email protected]>> wrote: > > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you can confirm the sender and know the > content is safe. > > > > > > > AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne > cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas > confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le > contenu ne présente aucun risque. > > > > > > > Greetings all, > > > Thank you for your replies. We have updated the document as described below. > The revised files are available here: > https://www.rfc-editor.org/authors/rfc9865.xml > <https://www.rfc-editor.org/authors/rfc9865.xml> > https://www.rfc-editor.org/authors/rfc9865.txt > <https://www.rfc-editor.org/authors/rfc9865.txt> > https://www.rfc-editor.org/authors/rfc9865.pdf > <https://www.rfc-editor.org/authors/rfc9865.pdf> > https://www.rfc-editor.org/authors/rfc9865.html > <https://www.rfc-editor.org/authors/rfc9865.html> > > > AUTH48 diffs: > https://www.rfc-editor.org/authors/rfc9865-auth48diff.html > <https://www.rfc-editor.org/authors/rfc9865-auth48diff.html> > https://www.rfc-editor.org/authors/rfc9865-auth48rfcdiff.html > <https://www.rfc-editor.org/authors/rfc9865-auth48rfcdiff.html> (side by side) > > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9865-diff.html > <https://www.rfc-editor.org/authors/rfc9865-diff.html> > https://www.rfc-editor.org/authors/rfc9865-rfcdiff.html > <https://www.rfc-editor.org/authors/rfc9865-rfcdiff.html> (side by side) > > > > > Please review and let us know if any further updates are needed or if you > approve the RFC for publication. > > > Thank you, > Sandy Ginoza > RFC Production Center > > > > > > >> On Sep 25, 2025, at 5:55 AM, Sehgal, Anjali >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> Thank you @Matt Peterson for sending out the response. >> I have also reviewed the content of the updated doc with editorial updates [ >> https://www.rfc-editor.org/authors/rfc9865-rfcdiff.html >> <https://www.rfc-editor.org/authors/rfc9865-rfcdiff.html> (side by side)]. >> They all seemed fine. >> Added a note around the 10) <!-- [rfced] As, "and Contributions" was added >> to the "Acknowledgements" inline below. >> Thanks >> Anjali >> From: Matt Peterson <[email protected] >> <mailto:[email protected]>> >> Date: Wednesday, September 24, 2025 at 5:52 PM >> To: "[email protected] <mailto:[email protected]>" >> <[email protected] <mailto:[email protected]>>, >> "[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>>, "Sehgal, Anjali" <[email protected] >> <mailto:[email protected]>> >> Cc: "[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>>, "[email protected] >> <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>>, "[email protected] >> <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>>, "[email protected] >> <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>>, "[email protected] >> <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>> >> Subject: RE: [EXT] [EXTERNAL] Re: AUTH48: RFC-to-be 9865 >> <draft-ietf-scim-cursor-pagination-11> for your review >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you can confirm the sender and know >> the content is safe. >> AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne >> cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas >> confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le >> contenu ne présente aucun risque. >> 1) <!-- [rfced] This document updates RFCs 7643 and 7644. As such, please >> review the errata reported for both RFCs and confirm that they are not >> relevant to this document. >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/rfc7643__;!!FJ-Y8qCqXTj2!bj6L_sjloeSF6ghwhfr3qv5DF3cgzT_jT1j93MoqS3a5QDpxuLUzJdLa6S7VkPh1RNiPdQToiNTpTsQC9RQ2uc7C5ZM$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/errata/rfc7643__;!!FJ-Y8qCqXTj2!bj6L_sjloeSF6ghwhfr3qv5DF3cgzT_jT1j93MoqS3a5QDpxuLUzJdLa6S7VkPh1RNiPdQToiNTpTsQC9RQ2uc7C5ZM$> >> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/rfc7644__;!!FJ-Y8qCqXTj2!bj6L_sjloeSF6ghwhfr3qv5DF3cgzT_jT1j93MoqS3a5QDpxuLUzJdLa6S7VkPh1RNiPdQToiNTpTsQC9RQ2SOqLK18$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/errata/rfc7644__;!!FJ-Y8qCqXTj2!bj6L_sjloeSF6ghwhfr3qv5DF3cgzT_jT1j93MoqS3a5QDpxuLUzJdLa6S7VkPh1RNiPdQToiNTpTsQC9RQ2SOqLK18$> >> --> >> >> [Matt] Reviewed. No errata is relevant to this document >> >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on >> https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!FJ-Y8qCqXTj2!bj6L_sjloeSF6ghwhfr3qv5DF3cgzT_jT1j93MoqS3a5QDpxuLUzJdLa6S7VkPh1RNiPdQToiNTpTsQC9RQ2-iFUo9U$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!FJ-Y8qCqXTj2!bj6L_sjloeSF6ghwhfr3qv5DF3cgzT_jT1j93MoqS3a5QDpxuLUzJdLa6S7VkPh1RNiPdQToiNTpTsQC9RQ2-iFUo9U$>. >> --> >> >> [Matt] No additional keywords needed. >> >> >> 3) <!-- [rfced] We have updated "Section 3.4.1 of [RFC7644]" to point to >> Section 3.4.2 instead, as Section 3.4.2 defines "totalResults". Please let >> us know if this is incorrect. >> >> Original: >> As described in Section 3.4.1 of [RFC7644] service providers should >> return an accurate value for totalResults which is the total number >> of resources for all pages. >> >> Definition from Section 3.4.2 of RFC 7644: >> totalResults The total number of results returned by the list or >> query operation. The value may be larger than the number of >> resources returned, such as when returning a single page (see >> Section 3.4.2.4) of results where multiple pages are available. >> REQUIRED. >> --> >> >> [Matt] Your update is correct. Thank you. >> >> 4) <!-- [rfced] We are having trouble parsing "and must value identical >> count". Please clarify. >> >> Table 3 Original: >> | invalidCount | Count value is invalid. Count | GET (Section | >> | | value must be between 0 and | 3.4.2 of | >> | | service provider's maxPageSize | [RFC7644]) | >> | | and must value identical count | | >> | | of the initial query. | | >> --> >> >> [Matt] >> OLD >> | invalidCount | Count value is invalid. Count | GET (Section | >> | | value must be between 0 and | 3.4.2 of | >> | | service provider's maxPageSize | [RFC7644]) | >> | | and must value identical count | | >> | | of the initial query. | | >> >> NEW >> | invalidCount | Count value is invalid. Count | GET (Section | >> | | value must be between 0 and | 3.4.2 of | >> | | service provider's maxPageSize | [RFC7644]) | >> | | and must be equal to the count | | >> | | value of the initial query. | | >> >> >> >> 5) <!-- [rfced] Is "Resources" here capitalized because it refers to the >> field in the sourcecode that follows, or should it be lowercase as it >> appears elsewhere (except for the code)? Please review. If it should be >> capitalized, please let us know if any other updates are required. >> >> Section 2.3 Original: >> (Resources omitted for brevity) >> >> Section 2 Original - similar use: >> (actual resources removed for brevity) >> --> >> >> [Matt] Yes “Resources” should be capitalized because it references the >> “Resource” property in the example response body. For consistency, >> “(Resources omitted for brevity)” should be used all instances: >> >> OLD >> The SCIM service provider in response to the query above returns >> metadata regarding pagination similar to the following example >> (actual resources removed for brevity): >> >> OLD >> The SCIM service provider in response to the query above returns >> metadata regarding pagination similar to the following example >> (Resources omitted for brevity): >> >> >> 6) <!-- [rfced] The following line extends one character beyond the >> 72-character limit. Please consider how this line may be reduced by one >> character or broken across lines. >> >> "schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"], >> --> >> [Matt] >> OLD >> { >> "schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"], >> "attributes": ["displayName", "userName"], >> "filter": "displayName sw \"smith\"", >> "cursor": "", >> "count": 10 >> } >> >> NEW >> { >> "schemas": [ >> "urn:ietf:params:scim:api:messages:2.0:SearchRequest" >> ], >> "attributes": ["displayName", "userName"], >> "filter": "displayName sw \"smith\"", >> "cursor": "", >> "count": 10 >> } >> >> >> 7) <!-- [rfced] We updated "Server provider" to "Service provider". Please >> let us know if any corrections are needed. >> >> Original: >> * In alignment with Section 2, cursor values are URL-Safe strings >> that are opaque to clients. Server providers should obfuscate >> cursors values to prevent clients from interpreting cursors or >> forging new cursors. Service providers should be able to easily >> detect forged cursor values and immediately return an >> invalidCursor as described in Section 2.1 >> --> >> >> [Matt] Thank you. "Service provider" is correct. >> >> >> 8) <!-- [rfced] Should "Clients should authenticate" be "Clients should use >> authentication"? >> >> Original: >> * Clients should authenticate to retrieve large result sets. >> --> >> >> [Matt] The original is correct. “Client should use authentication” is also >> correct and (maybe) more readable? >> >> >> 9) <!-- [rfced] Because "SCIM Server-Related Schema URIs" is a registry >> within the "System for Cross-domain Identity Management (SCIM) Schema URIs" >> registry group, and two of the actions are being made to values registered >> in the "SCIM Schema URIs for Data Resources" registry, we have altered the >> IANA Considerations to specify the specific registries being updated. >> Please review and let us know if any updates are needed. >> --> >> >> [Matt] alterations to add specific registries are good >> >> 10) <!-- [rfced] As "and Contributions" was added to the "Acknowledgements" >> section title in a recent I-D, it seems you'd like to recognize some of the >> individuals as Contributors. The RFC Style Guide allows for an optional >> Acknowledgements section and an optional Contributors section. We >> recommend dividing "Acknowledgments and Contributions" into two sections to >> clarify acknowledgements and contributors. Please review and let us know >> how to update the text. >> >> Original: >> 8. Acknowledgments and Contributions >> >> The authors would like to acknowledge the contribution of Paul Lanzi >> (IDenovate) in leading the writing of security considerations >> section. >> >> The authors would also like to acknowledge the following individuals >> who provided valuable feedback while reviewing the document: >> >> * Aaron Parecki - Okta >> >> * David Brossard - Axiomatics >> >> * Dean H. Saxe - Independent >> >> * Pamela Dingle - Microsoft >> >> --> >> >> [Matt] Danny please respond to this rfced comment >> [Anjali] Paul Lanzi should be considered under Contributors section as he >> led the security consideration section. Aaron, David, Dean, Pamela under >> Acknowledgements sections as they helped in reviewing the doc by providing >> critical feedback. Danny let us know if you think otherwise. >> >> >> 11) <!-- [rfced] Please review the "Inclusive Language" portion of the >> online Style Guide >> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/ >> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/>*inclusive_language__;Iw!!FJ-Y8qCqXTj2!bj6L_sjloeSF6ghwhfr3qv5DF3cgzT_jT1j93MoqS3a5QDpxuLUzJdLa6S7VkPh1RNiPdQToiNTpTsQC9RQ2lRqT8KE$> >> 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. >> --> >> >> [Matt] Reviewed. No changed needed >> >> >> Any email and files/attachments transmitted with it are intended solely for >> the use of the individual or entity to whom they are addressed. If this >> message has been sent to you in error, you must not copy, distribute or >> disclose of the information it contains. Please notify Entrust immediately >> and delete the message from your system. > > > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
