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 11) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!FJ-Y8qCqXTj2!bj6L_sjloeSF6ghwhfr3qv5DF3cgzT_jT1j93MoqS3a5QDpxuLUzJdLa6S7VkPh1RNiPdQToiNTpTsQC9RQ2lRqT8KE$<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]
