<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!-- [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://www.rfc-editor.org/errata/rfc7643
https://www.rfc-editor.org/errata/rfc7644
-->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2.3) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-scim-cursor-pagination-11" number="9865" category="std" consensus="true" submissionType="IETF" updates="7643, 7644" obsoletes="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.1 -->

  <front>
    <title abbrev="SCIM Cursor Pagination">Cursor-based Pagination of SCIM System of Cross-domain Identity Management (SCIM) Resources</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-scim-cursor-pagination-11"/> name="RFC" value="9865"/>
    <author initials="M." surname="Peterson" fullname="Matt Peterson" role="editor">
      <organization>Entrust</organization>
      <address>
        <email>matt.peterson@entrust.com</email>
      </address>
    </author>
    <author initials="D." surname="Zollner" fullname="Danny Zollner">
      <organization>Independent</organization>
      <address>
        <email>danny@zollnerd.com</email>
      </address>
    </author>
    <author initials="A." surname="Sehgal" fullname="Anjali Sehgal">
      <organization>Amazon Web Services</organization>
      <address>
        <email>anjalisg@amazon.com</email>
      </address>
    </author>
    <date year="2025" month="July" day="15"/>
    <area>IETF</area>
    <workgroup>SCIM</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>SCIM</keyword> month="September"/>
    <area>SEC</area>
    <workgroup>scim</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <?line 44?>
<t>This document updates RFC7643 RFCs 7643 and RFC7644 7644 by defining additional SCIM (System System for Cross-Domain Identity Management) Management (SCIM) query parameters and result attributes to allow use of cursor-based pagination in SCIM
service providers that are implemented with existing code bases, codebases, databases, or APIs where cursor-based pagination is already well established.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    System for Cross-domain Identity Management Working Group mailing list (scim@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/scim/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/ietf-scim-wg/draft-ietf-scim-cursor-pagination"/>.</t>
    </note>

  </front>
  <middle>
    <?line 49?>

    <section anchor="introduction">
      <name>Introduction</name>
      <t>The two common patterns for result pagination are index-based pagination
and cursor-based pagination.  Rather than
attempt to compare and contrast the advantages and disadvantages of
competing pagination patterns, this document simply recognizes that
SCIM (System
System for Cross-Domain Identity Management) Management (SCIM) service providers are commonly implemented as an
interoperability layer on top of already existing application
codebases, databases, and/or APIs that already have a well established pagination pattern.</t>
      <t>Translating from an underlying cursor-based pagination pattern to the
index-based pagination defined in Section 3.4.2.4 of <xref target="RFC7644"/> target="RFC7644" section="3.4.2.4"/>
ultimately requires the SCIM service provider to fully iterate the
underlying cursor, store the results, and then serve indexed pages
from the stored results.  This task of "pagination translation"
increases complexity and memory requirements for
implementing a SCIM service provider, and may be an impediment to
SCIM adoption for some applications and identity systems.</t>
      <t>This document defines a simple addition to the SCIM protocol that
allows SCIM service providers to reuse underlying cursors without
expensive translation.  Support for cursor-based pagination in SCIM
encourages broader cross-application identity management
interoperability by encouraging SCIM service provider implementations
for applications and identity systems where cursor-based pagination
is already well-established.</t> well established.</t>
      <t>This document updates RFCs 7643 and 7644 because it adds attributes to
existing structures from those documents, as described in this memo in <xref target="section2"/>. These changes are invoked when using the "cursor" parameter when making SCIM search requests using GET or POST methods.</t>
      <section anchor="notational-conventions">
        <name>Notational Conventions</name>
        <t>The
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t>
        <?line -18?> here.
        </t>
      </section>
      <section anchor="definitions">
        <name>Definitions</name>
        <t>This document uses the terms defined in section 1.2 of <xref target="RFC7643"/></t> target="RFC7643" section="1.2"/>.</t>
      </section>
    </section>
    <section anchor="section2">
      <name>Query Parameters and Response Attributes</name>
      <t>The following table describes the URL pagination query parameters for requesting cursor-based pagination:</t>
      <table>
        <name>Query Parameters</name>
        <thead>
          <tr>
            <th align="left">Parameter</th>
            <th align="left">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">
              <tt>cursor</tt></td>
            <td align="left">The string value of the nextCursor attribute from a previous result page. The cursor value <bcp14>MUST</bcp14> be empty or omitted for the first request of a cursor-paginated query. This value may only contain characters from the unreserved characters character set defined in section 2.3 of <xref target="RFC3986"/>.</td> target="RFC3986" section="2.3"/>.</td>
          </tr>
          <tr>
            <td align="left">
              <tt>count</tt></td>
            <td align="left">Specifies the desired maximum number of query results per page, e.g., 10.  A negative value <bcp14>SHALL</bcp14> be interpreted as "0".  A value of "0" indicates that no resource results are to be returned except for "totalResults". When specified, the service provider <bcp14>MUST NOT</bcp14> return more more, although it <bcp14>MAY</bcp14> return fewer fewer, results. If unspecified, the maximum number of returned is set by the service provider.</td>
          </tr>
        </tbody>
      </table>
      <t>The following table describes cursor-based pagination attributes returned in a paged query response:</t>
      <table>
        <name>Response Attributes</name>
        <thead>
          <tr>
            <th align="left">Element</th>
            <th align="left">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">
              <tt>nextCursor</tt></td>
            <td align="left">A cursor value string that <bcp14>MAY</bcp14> be used in a subsequent request to obtain the next page of results. Service providers supporting cursor-based pagination <bcp14>MUST</bcp14> include <tt>nextCursor</tt> in all paged query responses except when returning the last page. <tt>nextCursor</tt> <bcp14>MUST</bcp14> be omitted from a response only to indicate that there are no more result pages.</td>
          </tr>
          <tr>
            <td align="left">
              <tt>previousCursor</tt></td>
            <td align="left">A cursor value string that <bcp14>MAY</bcp14> be used in a subsequent request to obtain the previous page of results. Returning <tt>previousCursor</tt> is <bcp14>OPTIONAL</bcp14>.  <tt>previousCursor</tt> <bcp14>MUST NOT</bcp14> be returned with the first page.</td>
          </tr>
        </tbody>
      </table>
      <t>Cursor values are URL-safe strings that are opaque to the client.
To retrieve another result page for a query, the client <bcp14>MUST</bcp14> query the same service
provider endpoint with all query parameters and values being
identical to the initial query with the exception of the <tt>cursor</tt> value value,
which <bcp14>SHOULD</bcp14> be set to a <tt>nextCursor</tt> (or <tt>previousCursor</tt>) value that
was returned by the service provider in a previous response.</t>
      <t>For example, to retrieve the first 10 Users users with <tt>userName</tt> starting
with <tt>J</tt>, use an empty cursor and set the count to 10:</t>
      <artwork><![CDATA[
      <sourcecode type=""><![CDATA[
GET /Users?filter=userName%20sw%20J&cursor&count=10
Host: example.com
Accept: application/scim+json
Authorization: Bearer U8YJcYYRMjbGeepD
]]></artwork> U8YJcYYRMjbGeepD]]></sourcecode>
      <t>The SCIM service provider in response to the query above returns metadata regarding pagination similar
to the following example (actual resources removed for brevity):</t>
      <artwork><![CDATA[
      <sourcecode type=""><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/scim+json

{
   "totalResults":100,
   "itemsPerPage":10,
   "nextCursor":"VZUTiyhEQJ94IR",
   "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
   "Resources":[{
      ...
   }]
}
]]></artwork>
}]]></sourcecode>
      <t>Given the example above, to request the next page or of results, use the
same query parameters and values except set the cursor to the value
of <tt>nextCursor</tt> (<tt>VZUTiyhEQJ94IR</tt>):</t>
      <artwork><![CDATA[
      <sourcecode type=""><![CDATA[
GET /Users?filter=username%20sw%20J&cursor=VZUTiyhEQJ94IR&count=10
Host: example.com
Accept: application/scim+json
Authorization: Bearer U8YJcYYRMjbGeepD
]]></artwork> U8YJcYYRMjbGeepD]]></sourcecode>

      <t>The service provider responds with:</t>
      <artwork><![CDATA[
      <sourcecode type=""><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/scim+json

{
   "totalResults": 100,
   "itemsPerPage": 10,
   "previousCursor: "ze7L30kMiiLX6x",
   "nextCursor": "YkU3OF86Pz0rGv",
   "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
   "Resources":[{
      ...
   }]
}
]]></artwork>
}]]></sourcecode>
      <t>In the example above, the response includes the optional
previousCursor indicating that the service provider supports forward
and reverse traversal of result pages.</t>
      <t>As
<!-- [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 <xref target="RFC7644"/> [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.
-->
      <t>As described in <xref target="RFC7644" section="3.4.1"/>, service providers should
return an accurate value for totalResults, which is the total number
of resources for all pages.  Service providers implementing cursor
pagination that are unable to estimate totalResults <bcp14>MAY</bcp14> choose to omit the totalResults attribute.</t>
      <section anchor="section2.1">
        <name>Pagination errors</name> Errors</name>
        <t>If a service provider encounters invalid pagination query
parameters (invalid cursor value, count value, etc), etc) or other error
conditions, the service provider <bcp14>SHOULD</bcp14> return the appropriate HTTP
response status code and detailed JSON error response as defined in
Section 3.12 of
<xref target="RFC7644"/>.</t> target="RFC7644" section="3.12"/>.</t>
        <t>For HTTP status code 400 (Bad Request) responses, the following detail error types are defined. These error types extend the list of error types defined in section 3.12 of <xref target="RFC7644"/>, Table 9: SCIM 9 ("SCIM Detail Error Keyword Values.</t> Values") of <xref target="RFC7644" section="3.12"/></t>
        <table>
          <name>Pagination Errors</name>
          <thead>
            <tr>
              <th align="left">scimType</th>
              <th align="left">Description</th>
              <th align="left">Applicability</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">
                <tt>invalidCursor</tt></td>
              <td align="left">Cursor value is invalid. Cursor value <bcp14>SHOULD</bcp14> be empty to request the first page and set to the <tt>nextCursor</tt> or <tt>previousCursor</tt> value for subsequent queries.</td>
              <td align="left">
                <tt>GET</tt> (Section 3.4.2 of <xref target="RFC7644"/>)</td> (<xref target="RFC7644" section="3.4.2"/>)</td>
            </tr>
            <tr>
              <td align="left">
                <tt>expiredCursor</tt></td>
              <td align="left">Cursor has expired. Do not wait longer than service provider's <tt>cursorTimeout</tt> to request additional pages.</td>
              <td align="left">
                <tt>GET</tt> (<xref target="RFC7644" section="3.4.2"/>)</td>
            </tr>
            <tr>
<!-- [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 <xref target="RFC7644"/>)</td>
            </tr>
            <tr>      |
   |               | service provider's maxPageSize   | [RFC7644])    |
   |               | and must value identical count   |               |
   |               | of the initial query.            |               |
-->

              <td align="left">
                <tt>invalidCount</tt></td>
              <td align="left">Count value is invalid. Count value must be between 0 and service provider's maxPageSize and must value identical count of the initial query.</td>
              <td align="left">
                <tt>GET</tt> (Section 3.4.2 of <xref target="RFC7644"/>)</td> (<xref target="RFC7644" section="3.4.2"/>)</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="sorting">
        <name>Sorting</name>
        <t>If sorting is implemented as described Section 3.4.2.3 of <xref target="RFC7644"/>, target="RFC7644" section="3.4.2.3"/>,
then cursor-paged results should be sorted.</t>
      </section>
      <section anchor="implementing-cursors-as-the-only-pagination-method">
        <name>Implementing Cursors as the Only Pagination Method</name>
        <t>A service provider <bcp14>MAY</bcp14> require cursor-based pagination to
retrieve all results for a query by including a <tt>nextCursor</tt> value in
the response response, even when the query does not include the <tt>cursor</tt>
parameter.</t>
        <t>For example:</t>
        <artwork><![CDATA[
        <sourcecode type=""><![CDATA[
GET /Users
Host: example.com
Accept: application/scim+json
]]></artwork> application/scim+json]]></sourcecode>

<!-- [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)
-->

        <t>The service provider may respond to the above query with a page
containing defaultPageSize results and a <tt>nextCursor</tt> value as shown
in the below example (Resources omitted for brevity):</t>
        <artwork><![CDATA[
        <sourcecode type=""><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/scim+json

{
   "totalResults": 5000,
   "itemsPerPage": 100,
   "nextCursor": "HPq72Pax3JUaNa",
   "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
   "Resources": [{
      ...
   }]
}
]]></artwork>
}]]></sourcecode>
      </section>
      <section anchor="implementing-both-cursors-and-index-pagination">
        <name>Implementing Both Cursors and Index Pagination</name>
        <t>When a service provider supports both index-based and cursor-based pagination, clients can use the 'startIndex' or 'cursor' query parameters to request a specific method.  Additionally, service providers supporting both pagination methods <bcp14>MUST</bcp14> choose a default pagination method to use when responding to requests that have not specified a pagination query parameter.</t>
        <t>Implementers of SCIM service providers that previously supported only index-based pagination and are adding support for cursor-based pagination should use index as the default pagination method to avoid incompatibility with clients that expect index-based pagination behaviors when no pagination query parameters are specified.</t>
        <t>SCIM clients can query the <xref target="section4">service provider configuration</xref> target="section4">Service Provider Configuration</xref> endpoint to determine if index-based, cursor-based cursor-based, or both types of pagination are supported and which of these is the default.</t>
      </section>
    </section>
    <section anchor="querying-resources-using-http-post">
      <name>Querying Resources using Using HTTP POST</name>
      <t>Section 3.4.3 of <xref target="RFC7644"/>
      <t><xref target="RFC7644" section="3.4.3"/> defines how clients may execute queries without passing parameters on the URL by using the <tt>POST</tt> verb combined with the <tt>/.search</tt> path extension execute. When posting to <tt>/.search</tt>, the client would pass the parameters defined in <xref target="section2"/> in the body of the POST request. For example:</t>
      <artwork><![CDATA[
<!-- [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"],
-->

      <sourcecode type=""><![CDATA[
POST /User/.search
Host: example.com
Accept: application/scim+json
Authorization: Bearer U8YJcYYRMjbGeepD

{
   "schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"],
   "attributes": ["displayName", "userName"],
   "filter": "displayName sw \"smith\"",
   "cursor": "",
   "count": 10
}
]]></artwork>
}]]></sourcecode>

      <t>Which would return a result containing a <tt>nextCursor</tt> value which that may
be used by the client in a subsequent call to return the next page of
resources:</t>
      <artwork><![CDATA[

      <sourcecode type=""><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/scim+json

{
   "totalResults": 100,
   "itemsPerPage": 10,
   "nextCursor": "VZUTiyhEQJ94IR",
   "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
   "Resources": [{
      ...
   }]
}
]]></artwork>
}]]></sourcecode>
    </section>
    <section anchor="section4">
      <name>Service Provider Configuration</name>
      <t>The <tt>/ServiceProviderConfig</tt> resource defined in Section 4 of <xref target="RFC7644"/> target="RFC7644" section="4"/>
facilitates discovery of SCIM service provider features.  A SCIM
service provider implementing cursor-based pagination <bcp14>SHOULD</bcp14> include
the following additional attribute in a JSON document returned by the
<tt>/ServiceProviderConfig</tt> endpoint:</t>
      <dl>
      <dl spacing="normal" newline="false">
        <dt>pagination</dt>
        <dd>
          <t>A
        <dd>A complex type that indicates pagination configuration options. <bcp14>OPTIONAL</bcp14>.  The <bcp14>OPTIONAL</bcp14>.</dd>
      </dl>

      <t>The following sub-attributes are defined:
</t>
          <dl> defined:</t>
          <dl spacing="normal" newline="false">
            <dt>cursor</dt>
            <dd>
              <t>A Boolean value specifying support of cursor-based pagination. <bcp14>REQUIRED</bcp14>.</t>
            </dd>
            <dt>index</dt>
            <dd>
              <t>A Boolean value specifying support of index-based pagination. <bcp14>REQUIRED</bcp14>.</t>
            </dd>
            <dt>defaultPaginationMethod</dt>
            <dd>
              <t>A string value specifying the type of pagination that the service provider defaults to when the client has not specified which method it wishes to use. Possible values are "cursor" and "index".  <bcp14>OPTIONAL</bcp14>.</t>
            </dd>
            <dt>defaultPageSize</dt>
            <dd>
              <t>Positive integer value specifying the default number of results returned in a page when a count is not specified in the query. <bcp14>OPTIONAL</bcp14>.</t>
            </dd>
            <dt>maxPageSize</dt>
            <dd>
              <t>Positive integer specifying the maximum number of results returned in a page regardless of what is specified for the count in a query. The maximum number of results returned may be further restricted by other criteria. <bcp14>OPTIONAL</bcp14>.</t>
            </dd>
            <dt>cursorTimeout</dt>
            <dd>
              <t>Positive integer specifying the minimum number of seconds that a cursor is valid between page requests. Clients waiting too long between cursor pagination requests may receive an invalid cursor error response. No value being specified may mean that there is no cursor timeout or that the cursor timeout is not a static duration.  <bcp14>OPTIONAL</bcp14>.</t>
            </dd>
          </dl>
        </dd>
      </dl>

      <t>Service providers may choose not to advertise Service Provider Configuration information regarding default pagination method, page size size, or cursor validity. Clients <bcp14>MUST NOT</bcp14> interpret the lack of published Service Provider Configuration values to mean that no defaults or limits on page sizes or cursor lifetimes exist, or that there is no default pagination method. Service providers may choose not to publish values for the pagination sub-attributes for many reasons. Examples include:</t>
      <ul spacing="normal">
        <li>
          <t>Service providers containing multiple resource types may have different values set for each resource type.</t>
        </li>
        <li>
          <t>Default and maximum page size may be determined by factors besides or in addition to the number of resources returned, such as the size of each resource on the page.</t>
        </li>
      </ul>
      <t>Before using cursor-based pagination, a SCIM client <bcp14>MAY</bcp14> fetch the
Service Provider Configuration document from the SCIM service
provider and verify that cursor-based pagination is supported.</t>
      <t>For example:</t>
      <artwork><![CDATA[
      <sourcecode type=""><![CDATA[
GET /ServiceProviderConfig
Host: example.com
Accept: application/scim+json
]]></artwork> application/scim+json]]></sourcecode>

      <t>A service provider supporting both cursor-based pagination and index-
based pagination would return a document similar to the following
(full <tt>ServiceProviderConfig</tt> schema defined in Section 5 of <xref target="RFC7643"/> target="RFC7643" section="5"/>
has been omitted for brevity):</t>
      <artwork><![CDATA[

      <sourcecode type=""><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/scim+json

{
   "schemas": [
      "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"],
      ...

   "pagination": {
      "cursor": true,
      "index": true,
      "defaultPaginationMethod": "cursor",
      "defaultPageSize": 100,
      "maxPageSize": 250,
      "cursorTimeout": 3600
   },

   ...
}
]]></artwork>
}]]></sourcecode>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This section elaborates on the security considerations associated with the implementation of cursor pagination in SCIM. This document is under the same security and privacy considerations of those described in <xref target="RFC7644"/>. It is imperative that implementers additionally consider the following security aspects to safeguard against both deliberate attacks and inadvertent misuse that may compromise the system's security posture.</t>
      <section anchor="threat-model-and-security-environment">
        <name>Threat Model and Security Environment</name>
        <t>The threat landscape is characterized by two primary types of actors:</t>
        <ol spacing="normal" type="1"><li>
            <t>Unauthenticated and Authenticated Malicious Actors: These individuals or entities represent a malevolent threat. Their objectives include unauthorized access to data, alteration, or deletion through cursor-enabled queries. They may also seek to deplete service provider resources deliberately, aiming to cause a denial-of-service state, thereby reducing service availability.</t>
          </li>
          <li>
            <t>Authenticated Benign Users: This category includes legitimate users who, due to confusion or a lack of understanding, inadvertently engage in actions that consume service provider service-provider resources excessively. Such actions, while not ill-intended, ill intended, can lead to unintended denial of service by overwhelming the service provider's capacity.</t>
          </li>
        </ol>
      </section>
      <section anchor="confidentiality">
        <name>Confidentiality</name>
        <t>To ensure that confidential data remains appropriately secured:</t>
        <ul spacing="normal">
          <li>
            <t>Implementers <bcp14>MUST</bcp14> ensure that pagination through results sets is strictly confined to the data that the actor's current identity has been authorized to access. This holds true even in cases where the actor has obtained a cursor pertaining to a result set that was generated by a different actor.</t>
          </li>
          <li>
            <t>Authorization checks <bcp14>MUST</bcp14> be continuously applied as an actor navigates through the result set associated with a cursor. Under no circumstances should possession of a cursor be interpreted as granting any supplementary access privileges to the actor.</t>
          </li>
          <li>
            <t>When possible, service providers <bcp14>SHOULD</bcp14> invalidate all cursors corresponding to an actor immediately following a change in permissions. This ensures that any queries executed post-permission change, utilizing old cursors, will be denied. As an alternative approach, service provider providers may opt to retain the existing cursors but must ensure that any metadata tied to the result set, such as record counts, is updated to reflect the new permissions accurately.</t>
          </li>
          <li>
<!-- [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
-->

            <t>In alignment with <xref target="section2"/>, cursor values are URL-Safe URL-safe strings that are opaque to clients.  Server  Service 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 <tt>invalidCursor</tt> as described in <xref target="section2.1"/></t> target="section2.1"/>.</t>
          </li>
          <li>
            <t>The service provider <bcp14>MUST</bcp14> handle error scenarios without exposing sensitive data. For instance, if an actor attempts to access a page of results outside their authorized scope, or if a request is made for a non-existent page, the service provider should respond with identical error messages, so as not to disclose any details of the underlying data or the nature of the authorization failure. It is acceptable, however, for the service provider to log different messages to a log accessible by administrators or other authorized personnel.</t>
          </li>
        </ul>
      </section>
      <section anchor="availability">
        <name>Availability</name>
        <t>The concern for availability primarily stems from the potential for Denial of Service Denial-of-Service (DoS) attacks. If the service provider elects to retain substantial data or metadata for each cursor, numerous initial queries that allocate cursors could strain and eventually exhaust service provider service-provider resources. Such an attack could be orchestrated by an attacker with malicious intent or could occur unintentionally as a result of client testing or bugs.</t>
        <t>To mitigate risks, the following strategies are recommended for service providers:</t>
        <ul spacing="normal">
          <li>
<!-- [rfced] Should "Clients should authenticate" be "Clients should use authentication"?

Original:
   *  Clients should authenticate to retrieve large result sets.
-->

            <t>Clients should authenticate to retrieve large result sets.  Anonymous queries yielding numerous results, results may return an HTTP status code 400 (Bad Request) with the error type "tooMany," as outlined in <xref target="RFC7644"/> section 3.12.</t> target="RFC7644" section="3.12"/>.</t>
          </li>
          <li>
            <t>Implement rate limiting to control the volume and cadence of cursor requests. This approach should adhere to established standards for rate limiting, limiting; details of which can be found in <xref target="RFC6585"/>.</t>
          </li>
          <li>
            <t>Allow administrator of the service provider to set a ceiling on the number of cursors permissible at any given time or to specify a maxPageSize value. Guidance on configuring such values should be documented in the implementation administrator/installation guide.</t>
          </li>
          <li>
            <t>Cursor invalidation mechanisms (including mechanisms triggered by permissions changes) must be designed to be resource-efficient to prevent them from being exploited for DoS attacks.</t>
          </li>
        </ul>
      </section>
      <section anchor="other-security-references">
        <name>Other Security References</name>
        <t>Using URIs to describe and locate resources has its own set of security considerations considerations, as discussed in Section 7 of <xref target="RFC3986"/>. target="RFC3986" section="7"/>.  Implementations should also refer to <xref target="BCP195"/> and <xref target="RFC9110"/> for additional security considerations that are relevant for underlying TLS and HTTP protocols.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This specification requests IANA
<!-- [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 amends values registered in the SCIM Server-Related "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.
-->

      <t>IANA has amended the "System for Cross-domain Identity Management (SCIM) Schema URIs" registry group established by <xref target="RFC7643"/>.</t>
      <t>For target="RFC7643"/> as described below.</t>
<t>IANA has updated the "SCIM Schema URIs for Data Resources" registry as follows:</t>
<ul>
      <li><t>For the <tt>urn:ietf:params:scim:api:messages:2.0:ListResponse</tt>, add <xref target="section2"/> of this document has been added to the References column.</t>
      <t>For column.</t></li>
      <li><t>For the <tt>urn:ietf:params:scim:api:messages:2.0:SearchRequest</tt>, add <xref target="section2"/> of this document has been added to the References column.</t>
      <t>For column.</t></li>
</ul>
<t>IANA has updated the "SCIM Server-Related Schema URIs" registry as follows: </t>
<ul>
      <li><t>For the <tt>urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig</tt>, add <xref target="section4"/> of this document has been added to the References column.</t> column.</t></li>
</ul>
    </section>
    <section anchor="change-log">
      <name>Change Log</name>
      <t>RFC Editor: Please remove this section in the release version of the document.</t>
      <t>-08</t>
      <ul spacing="normal">
        <li>
          <t>Fix several typos and wording consistencies</t>
        </li>
        <li>
          <t>Add reference

  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6585.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7643.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7644.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0195.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
      </references>
    </references>

<!-- [rfced] As "and Contributions" was added to RFC7644 the "Acknowledgements" section title in Security Considerations</t>
        </li>
        <li>
          <t>Adjust indenting and wording a recent I-D, it seems you'd like to clarify the definition recognize some of the pagination attribute in serviceProviderConfig</t>
        </li>
        <li>
          <t>Reference individuals as Contributors.
The RFC section 2.3 (not section 2.2) Style Guide allows for unreserved characters</t>
        </li>
        <li>
          <t>Reference section RFC 7644 3.4.3 (not an optional Acknowledgements section 3.4.2.4 ) for POST query</t>
        </li>
        <li>
          <t>Added updates 7644, 7643</t>
        </li>
        <li>
          <t>Changed IANA considerations to add and an
optional Contributors section.  We recommend dividing "Acknowledgments and Contributions" into two sections of this document to References column of SCIM Schema URIs for Data Resources impacted by this document</t>
        </li>
      </ul>
      <t>-07</t>
      <ul spacing="normal">
        <li>
          <t>Minor grammar change</t>
        </li>
        <li>
          <t>Add informative reference to BCP195 clarify acknowledgements and RFC9110</t>
        </li>
      </ul>
      <t>-05</t>
      <ul spacing="normal">
        <li>
          <t>Various updates in response to WG/IETF Last Call feedback</t>
        </li>
      </ul>
      <t>-04</t>
      <ul spacing="normal">
        <li>
          <t>Added IANA Considerations section</t>
        </li>
        <li>
          <t>Added Security Considerations section</t>
        </li>
        <li>
          <t>Added Backwards Compatibility Considerations section</t>
        </li>
      </ul>
      <t>-03</t>
      <ul spacing="normal">
        <li>
          <t>Minor grammatical/typo fixes, rename + changes contributors.  Please review and let us know how to maxPageSize SCP definition</t>
        </li>
      </ul>
      <t>-02</t>
      <ul spacing="normal">
        <li>
          <t>Typos/semantics, acknowledgements, expansion of cursorTimeout SCP definition</t>
        </li>
      </ul>
      <t>-01</t>
      <ul spacing="normal">
        <li>
          <t>Updated after Httpdir review.</t>
        </li>
      </ul>
      <t>-00</t>
      <ul spacing="normal">
        <li>
          <t>Adopted by SCIM WG.</t>
        </li>
      </ul>
    </section>
    <section anchor="acknowledgments-and-contributions">
      <name>Acknowledgments update the text.

Original:
8.  Acknowledgments and Contributions</name>
      <t>The Contributions

   The authors would like to acknowledge the contribution of Paul Lanzi
   (IDenovate) in leading the writing of security considerations section.</t>
      <t>The
   section.

   The authors would also like to acknowledge the following individuals
   who provided valuable feedback while reviewing the document:</t>
      <ul spacing="normal">
        <li>
          <t>Aaron document:

   *  Aaron Parecki - Okta</t>
        </li>
        <li>
          <t>David Okta

   *  David Brossard - Axiomatics</t>
        </li>
        <li>
          <t>Dean Axiomatics

   *  Dean H.  Saxe - Independent</t>
        </li>
        <li>
          <t>Pamela Independent

   *  Pamela Dingle - Microsoft</t>
        </li>
      </ul>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="RFC6585">
          <front>
            <title>Additional HTTP Status Codes</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <date month="April" year="2012"/>
            <abstract>
              <t>This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6585"/>
          <seriesInfo name="DOI" value="10.17487/RFC6585"/>
        </reference>
        <reference anchor="RFC7643">
          <front>
            <title>System for Cross-domain Identity Management: Core Schema</title>
            <author fullname="P. Hunt" initials="P." role="editor" surname="Hunt"/>
            <author fullname="K. Grizzle" initials="K." surname="Grizzle"/>
            <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/>
            <author fullname="C. Mortimore" initials="C." surname="Mortimore"/>
            <date month="September" year="2015"/>
            <abstract>
              <t>The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP.</t>
              <t>This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange Microsoft

-->

    <section anchor="acknowledgments-and-contributions" numbered="false">
      <name>Acknowledgments and use with cloud service providers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7643"/>
          <seriesInfo name="DOI" value="10.17487/RFC7643"/>
        </reference>
        <reference anchor="RFC7644">
          <front>
            <title>System for Cross-domain Identity Management: Protocol</title>
            <author fullname="P. Hunt" initials="P." role="editor" surname="Hunt"/>
            <author fullname="K. Grizzle" initials="K." surname="Grizzle"/>
            <author fullname="M. Ansari" initials="M." surname="Ansari"/>
            <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/>
            <author fullname="C. Mortimore" initials="C." surname="Mortimore"/>
            <date month="September" year="2015"/>
            <abstract> Contributions</name>
      <t>The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service. Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7644"/>
          <seriesInfo name="DOI" value="10.17487/RFC7644"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used authors would like to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for acknowledge the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity contribution of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used <contact
      fullname="Paul Lanzi"/> (IDenovate) in protocol specifications. This document aims to reduce leading the ambiguity by clarifying that only UPPERCASE usage writing of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">
          <reference anchor="RFC8996" target="https://www.rfc-editor.org/info/rfc8996">
            <front>
              <title>Deprecating TLS 1.0 and TLS 1.1</title>
              <author fullname="K. Moriarty" initials="K." surname="Moriarty"/>
              <author fullname="S. Farrell" initials="S." surname="Farrell"/>
              <date month="March" year="2021"/>
              <abstract>
                <t>This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.</t>
                <t>This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.</t>
                <t>This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document
      Considerations section.</t>
      <t>The authors would also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="195"/>
            <seriesInfo name="RFC" value="8996"/>
            <seriesInfo name="DOI" value="10.17487/RFC8996"/>
          </reference>
          <reference anchor="RFC9325" target="https://www.rfc-editor.org/info/rfc9325">
            <front>
              <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
              <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
              <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
              <author fullname="T. Fossati" initials="T." surname="Fossati"/>
              <date month="November" year="2022"/>
              <abstract>
                <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used like to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over acknowledge the years, following individuals
      who provided valuable feedback while reviewing the industry has witnessed several serious attacks on TLS and DTLS, including attacks on document:</t>

    <contact fullname="Aaron Parecki">
      <organization>Okta</organization>
    </contact>

    <contact fullname="David Brossard">
      <organization>Axiomatics</organization>
    </contact>

    <contact fullname="Dean H. Saxe">
      <organization>Independent</organization>
    </contact>

    <contact fullname="Pamela Dingle">
      <organization>Microsoft</organization>
    </contact>
    </section>

<!-- [rfced] Please review the most commonly used cipher suites and their modes "Inclusive Language" portion of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and DTLS. These recommendations let us know if any changes are applicable to the majority of use cases.</t>
                <t>RFC 7525, an earlier version needed.  Updates of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 nature typically
result in view of recent attacks.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="195"/>
            <seriesInfo name="RFC" value="9325"/>
            <seriesInfo name="DOI" value="10.17487/RFC9325"/>
          </reference>
        </referencegroup>
        <reference anchor="RFC9110">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) more precise language, which is a stateless application-level protocol helpful for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol readers.

Note that are shared by all versions. In our script did not flag any words in particular, but this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8Vc63Ibx5X+jyq+Qy9cG0kOAJEUbUuoOAlFyTIdXRiRitdR
VGFjpgG0NRd4eoYk5DjPss+yT7bn1j09wECSs6Wsf8jgXLpPnz6X71x6xuPx
3qC2dWamanjSVK6sxjPtTKrO9MIWurZlocq5Oj85faZeGlc2VWLccG+gZ7PK
XMFLdIffjN6BJ9IyKXQO46aVntdja+r52CU2Hyc8zSo8PD442BvsDRJdm0VZ
rafK1SlesKtqquqqcfXh/v6D/UOYtTJ6qk4fX3yzN7guq7eLqmxWU6Jub/DW
rOFaOlWvT4vaVIWpx49w6hHdf7M3aFYpTOGm6qsvj+6N8N8jnMbVukj/rrOy
AGLXxsGVXFf1339qSnq6KPcGKwvD1mUyUkB6XZm5g1/rHH/AwK6Z5dY5WMrF
emU8gUBuUy/Laro3UEqN6V/FLHmm61qdGaDSlQXfKKuFLuw7YshUPS5o3XzL
5NpmU5XDS5OVvPRHw09MkjLnp6oSN9Gkti6r7Rkf6aJYq7+WWVaYqm/G0yI1
KwP/FN1ZU3zxj+/4xTRM1xn8uPhRZ1adm+VCZ32DH+f6HQjS92YGD1VXNkEu
R5NoGsAt/qjpQZ5lb1CUFSzaXhli4ctvTu49uP+l//3lF/e/8L9xQ6PfR1MS
n2Leef/hydnBg/DKg4ODfXpsPB4rPXN1pZMa/75YWqdAeJscWKFEZvwkQGnq
J1GztUrN3Ba2WCidAuNhrTpjXbl9vna1yRWQoE6q0rnxoxLWWqhT5LCt1yAD
hV4YnOSO+qkx1VqtdAXsxP2laSrjmqxWsOuVnTVIRF0qnWXltWqcQa1MYoVt
9UnBNKwSjpmtVlV5ZVMcuF5qGLIyyuarjGaHV69tvVTmxroal5KUqVE4Jsg4
LF7LT1jI8dmpU9dLA6/vnBpoz0BL07W6NlmmDGjXDLZ2adKJ53Zu0zQz+Ndn
IHZ1VaZNgi8z942qr0sgIs9huBWsHlTZER+FIdFstBCQ2ZstQkD5gIU7qJyA
BOga1oHswEdhknxVI39h3hWOSm+XQJx2cB2I0umVLmrYMd6c1LroSjkH8wVv
GmJgRKCnfwRjxGLlkP1rWFFSLkBNDG/M3uBfkJ3tPUb6mX8wRbzPGmlHxQCa
ypWp9MxmOFym18ALILcuVyhXfgeDSOjVKrOJMBblY1s8gCl3vYiwkMkgS30F
3NuShh4ukYBcVLpwmaZp51WZw8CqgS2usjUJ5w65kyFwC2G3cI19UsH6CpdQ
QwwJnbo3OZocTo5w3a9Fs9FXZLUF22Fok35qbEVbZFi5N1mOs86bDLkNRMBb
TMMW2eAzwDjTXRFmZhxeKGhUEWcmGo0ksQCfpze9UXAgwWSnau3eIuXDaI21
5yC5YVsksA+wRSTaGWwpbDjOmZscnK1fHUoIaRm84SWGdr5/xUx2rtdqhrqC
Ugaeh0S7LkWMdVquiCCUY1fmJhYj1iLrBdqRxLvJtgHmHYPHWWdMsLSy1Uwf
0AXeucxEjchKun7SyYxWBk3o1gY5MoVlA0OYG/CGDnxHzE9g+3mzWgEEoEV9
0P6aIgHERCZiVpUaRSUhhY440TIhD1rdo6PgbPxoSG+/HIatYx6D+ACVH+T6
+0060NK16eNNm77TYzoVfCY7TJNo5LutcRdd17Uhy8XcgDMGj9Cgzon8l/CW
nwF1BuYzLoGXWZfJuKJAwx97g9dvbn/mWLsP70xAUQy8nYClJ+NNLuOqfIt+
D9WucTglStKQOTBsHTE/keu3Ect1lSxJa4ANTt5+8vgC/ePZi/MLIAPITVmU
P/tMPS95MwAYnJTFFXKedoZdHWBWhaDVqeGzV+cXwxH/Xz1/Qb9fPv7zq9OX
jx/h7/Nvj58+DT8G8sT5ty9ePX3U/mrfPHnx7Nnj54/4ZbiqOpcGw2fHPwxZ
jYcvzi5OXzw/fjoMvAy7iewCfZkh04Ahq8qwIxl0+A/Q6n/+++BI/fzzf8C2
Hx4cPPjlF/nj/sFXR/AHMpJnI6/EfwLT1wMQT+ApjgJaqxK9srXOeI/dsrwu
FArnZDD4/DVy5s1U/W6WrA6Ofi8XcMGdi55nnYvEs+0rWy8zE3su9UwTuNm5
vsHpLr3HP3T+9nyPLv7uDxmYOzU+uP+H3w9EhB4RyBS52VA2J34J9iZ3sXsT
BVAHk8PItd17w7DrzwQ4z7qAE+K7Fcxh1HGrlz8HTfrFy+y8ROtKSgNmwARN
ZEJevXwam8ItZMtAjrTnPf6ckPk/WgLVP4ALOA17lH/gzUt+9xLuXZCDrHDA
K501BI6RmMLc1BKbBlsjqAKMprmyZeMiWGnIWAhNMhLJGIg/AsQ1KnmZ2xp1
ABeCc8xtBRBRlkToSXUjXHiWuDBhl83DouskTUCQidgO7BNGIMQi7/ObAmhD
VJDGt52p+zb6cHLPbzSGSW8mnktlU9TIpPOVSezcyj7BrlkEFLm+sXmTq6LJ
ZwgC57JlAjQUuCBizUiZyWIyUgf74ASPgbMLiqxkOaxNW1ZCDfeH9HjYFbiA
EAf9kYBeiK9xMsoshFlbswNDNRUu1dwkZsV+d1iDUc1e8rMwwfcEn2R56Yjx
0qZv9MZCRlQ5IjGdobtfLNElgXb6e3NzbaoWa53OYSs2xt/mW6DU8h6Bx+4j
hPbl56mirMvXw01NHH6Enu3CHZE/bYkpUNZhA9N2Y0nLRcUeM2DoVbBWfVB+
jruKIfpGW4isg71qnJ/QNTOHGlG0mgHbWc5I1L1mElnMOWH0+RZWcwy33gf9
aWMB5mYNxK0dmsWn9K3eeXkiD8/c8jggw5iPzUFnOG8KggVgQ+KHZH2uyyDf
zJuawBUKNAg6CV1kcJzXUm+NPhG7g7HbYvnLsPQtGkCOvYcCJd66HRQq1lJK
JbRmkbgYi3uPj2GJP4kWy/oPnmTs9NwvPcpdlCsNi/QBQJJZWDjMcoGGBJ41
GHAWJQX4Ea/JdGiWg1H0Ji+ExYMUFjTRa+3eINgPU6SrEswbLxHlqjdrIwuY
GSAZoDNB7QTAnxBLjlz7dwO3WBgl2YoXgnOj8fYG10sLsFOwyMyQgcF0UFdC
b8MKN/fpjggQR0bXOrINOyyU2IzIP9KWEaL9BmYwNxrjjBEHUsLwds8P9tUr
ZySWUpcgpdVz4NAl7KMmTQYq6M53lyPKZEH8yN5VBB7ZSOvDLULvhRNJtu6f
//zn3gDh9l2a4w9zmwHrv/aT/OfhvruGf777DY/1G3r/64P9vcG3paunnnbO
MB4nyPVpHCHdxRT1b3+ktOwxpW9DEvMhwFRgzqv7P3yX/PDDy2c/zp4Ys3ok
NLHN3hGWFa2REDng/dez8sorDwYwtcaMClxY6CrdSCVB+GszDfG5jNC6B1mT
ug0AoQHZ8t4Uty4vrwSrYL4egr47LRu/vbg4u3swOVCH+/vqxZ9ABwGLgLyO
OYu9gyugzZS77Trh6cH+/oivW4wpz0x1BjqH1+VyK6fD6fAvf311YdfLx3/+
7sHR6cuhPOKSpck1DPZ6CAyZYslgSurlpkjAFGKDaW6cQ8M5PZzsT59CwOgt
yvCNjNKWKaavmVT4bzKZ0M9fAAD/ErbsCSCYQhSQeUg7IpIthrTrrQIsYNml
RA9ZjPdZA/E1QahZzmUjRcNB8bu6fNll0uWdDylA0aMAX3cH+Xfrw5YqsB6k
bBw+kSiqXbKogjB2beRUDd+Zr57e23/7zNqn//XlzbBHZtXwh7ev7r345v6X
Z+/2qydXW0Kr/l1Se9ovspxUZCsjcIihPqfhsDLTXbYHKgFX9DoDQWAUuV2D
WeLMOgwE0kfJMfwBVieACgE2SOnxRp4mzrkedDKuPWk6iP6bDKYTTA5eQicg
1Ais2KNRBBbtvGInaSUixjsCz0m7WrNIQECAIaZSt2FnJwfKmgTci3KsHoo0
BWFzUGUMaHNCfTFJCNWSZVmy5Ufk2BLnnwmw3eeMotqrqSpMS7Zh+OSA4NIp
xplbe0UZwoKsjy2ASTbdisVxGcFE3fZPxVBzJE5X/jB1coeqPwyoiCAsAhSc
hnU7wi2BKrJ5VEFZwc1VZZFHqO+4syKugAzqxnHliaor4AltBjLz3fmL5zxl
K9s6znPsDVqZOjjsiFTAKzhZZ4ojMDK3H2rMeJCNv9OGBaMN38qUCAk1GCPG
pkKATy7Gt8FkGE7pq8xyRiC+3RO5b1E+UhckVQ+4tA2RGRHxmIb5E5e51V/I
tUw4irtES4O28nIzkFPHbDsljczRhmx7G2zE6BsVSB6YdG+08JPx2oaXbCF/
C+HYxXUcWw9GjRQ6CmVQXi0sEQgGhwcesVOy6XDsDq/L3KwwqbG1rqXGfaF7
E/WohEgMYLwGXczKYiFlwC0RvuU8Cr+wuSmb+jJecFTwZTPy8VR67vvEzEmr
bl3eR9fzBuYExs9MfW0As+wLi7dIzvUNOrtz+453gV6UsUMwwgouoUYnJAFr
+JELaWO6yFyRiEpEB4bsvBTATwbLSSBv3WZVsnUS3arcva5aAPbFaL1Nr7UF
MfEWFBrBNFKZABJOY0t+IlUezS7iBQbsEfXPKHVPjqsnf0TpISqW7UxFYBWj
DUGzLFAXhZ4YdbF75vpaRzdkowpaaWvyDMJUylS0sUNagjVBQfapjzhsjKz8
ZtjWhyL/FTT4PpSH2U1Bet4EcKgThb2clSJPgmkKNrZzDewK8huygTBML6N8
jQDrZTTLzGB7RAiIAqjqZG0/cSSkvtjfjT/7oiE1/Pbsp68Oz/TNve9e6ef6
0yFL9SFouakwD8Hpt1oD24BtQjeRzuBLlH7tQSMBOc5wlLgi/57ejJFkZcBV
Y+WfQyx1i3IHNPktdCC3+O1b21FXbKJ9TjiRohymooPZztajPtDZ5huJ6ki5
pbDH6SLBdNrL7PaDSAmSLwlGUgZC2oFAyWhRgwQqcsgws27sKKGQPodNQpp9
f96Obh/va8HWyeqMVOF2NEmQulVcacdq7EdUvMX6UnGXJET7KsN7uKOvSotA
iHpuaisIhYyDlwFaAJbik3oXtTMDDLRUu0dOF+V7y0+4rsBnYiXzLha6NhX4
ekumwVrN7QKjEBi+rTMf3Wnzg7CyFCfLsZBn5zHdoy4D0RahkDEyhG3caG1q
twu3hKMbdtrO+DBHODyJ6nq4aa3l4wo1YWCsT+NzsZPtutjQbgFWNfAErbm5
MQkWzwST+T4JoNg5TlQFFpdFKASCq2vL65c4PVhuU82wF2VmO/niy7sTrq1f
Yi/PkmG0oxCIp5Yyz6rkwiFwuX2lk869JlFEwjj13VIWYe9Oj4Dy3qNM1x4V
US1fFHWiev0nPUIO1BPyKbMqwdv8erdwTsRJsBP8QlstoqFS61aZXmMWFTsG
fEY1PM6JJvRW0ZPKXau/DR041+Xfht5vJcGvhSuIN8n/xc7mexJo3i4f5Psc
QoQKej0/KwNI5t7AV0Ikmy1SsFkXSRCOccLaB6RxDYqCUdaY/7+sVBcUfCBH
+m8EBSFBcubN4ElsBtvsxFEoXl7elXf8K/zGZVvq7WnF22zCm+sEfQKVikHo
EkCQ1Xqnu1Nzo6lpiCrO/Q2wfYmdbZcica4Aa8bibUogivzapgJYBeUqQmfG
RpFlb7CTI95xkNzFfVdTrAFy0x65CPaGbfU8orjjliThB3yIynfdijIoxjiq
FkcpDaICRMAnveAn0vGwLDMDvlGKkeRB1zE62N2OPFG+JWciY5NH/FVD9/v+
7ZHbCEIe8SGdzNVpEommopwcsrjrhHdnRWUiwpshMBPTg9mGLp4Ta8XIx2IJ
0S25nxss10SdleBEMeETVT9DMxp1aNH6sZUi7OjWgilkkoXCgJa6M7AdAxMc
vQv24CxuYeCAa7t7gBepJXNgNxdoo8h0skVklJPYReAGaX3dFTtJ43JZBjYP
H7wmJXERcb5TR2gvfCTO3T4fMZX0uc6byteUQYySmpWb06JJha2/Vm8vvpNC
+tjlg+fr0gQGlsomnHj2+VpuJ7JpSAsJPzi8mKgTQXCY62LQVFLKKzwv40Qi
H2ITjuETY6+4w7ebKe7mZCfqeSkyRoXviPk4TI7qHTVDkPiEKhhzRtEm6W6B
TG6JuGlK4kI0l4qh29SH7Tw+zi6hGo6AQUcKTqS2cOEDTi0cHyGm+ILszoBm
xLx3mLcIgRLvDkQ17VaEronQKSU9Jwk1cq8a3x//AfLEVMCKWu4WZWuXYPLM
Ai4jPB5IcxFtmZ0b5LDjPv9RvANhk3aut69ZZ5vbshxPrdfEOHLseiJ8ItcF
ip525MMeM5Z23h2Tg/q8Z/YIMubYvo8ZoIA2OMRCAincTu18Dov06VVu2MK5
jabu3uitCc72SNjAXe9sMNr9FvsQoj6yCwBeaoxKZ8bZlBmPpmeje71jdULV
nu3OCJgD1EgozZI136BQgi3ps9kbPDRzbDHiqGtnikXHQS9lNkEUkiUDlQ8I
XkA4oU0xRmNRwwzVv8EmztcsVu85MhQC3Q8kK3sR1P8hedmT5t1MAO3stcNG
ekIlEIFs3tyIaeJjP9jDoTZbOPYGt/H8iLrcAREZ9PdB5i82mnsRe8zQsn/S
hGcUhPjQoT8YkQenCQilhKI9C/RRiY9ApEbfniadqhCitNFlXTUmvCcIafPq
DjyI4ZWM0/csIZU4YsPbEYiBW4dfRLc6Lh5u3vtyf5/jqJEshpbVjajgJUx3
AQfQPlT+xIZ0ePvaoMn0rKwI7ouqO/9m0nkTzIQrE6vrOKnSPQ/SYvSewyrS
nRxEFX7T8Zi4JU4mRtFfVfZKJ1tEUPKEDmvEZf+2JKtOayn/0CtXPqaJ05k6
StGG8TfKsi0tiDQYhmOv4KIBP630AvwA1stQgVOTAR3UNgB+BtysHIIpGAng
WnPrONEMpJAPg6ALjJuV5DMfk7nl2lkxCQWRpq8xXSzBW4EdLWEuGjzs7uPi
ylZlwWd65HQjP5zBcy7RK3K0obsbhIsjxusSWZxrTET67CA7FFLig4l6VeDx
Yq7o+RThcefKMwAfCbXwHfObUq3GCBK0r9EZeSU6DGTJ76yw3xxPfQAbMnMF
cRnmM4lgAssWPNXsRxTNq9YhYw+E5LCQDDC8jvYDW9lG2GEt0kEAAzhkJLSq
qPFa7KuhPoo01HxxtjVtBlAJe2vMW06sgqDU/X1F4j3b/cYMvwaLy9lCPnqE
RrSwOhuX87EfBFElN9BUZobII20SFjK+r680WG1OT8OWH042+PwQRlwU3PQ4
ZTXyZ9nbRpzMLKw0iDTcHbksR4BkDZ86LeYNJTupTujBICkgHU8HckaxyGZ4
GmyBAAQxRcLKx14WfjX5ezmE3WgOj7ZlgEvPCWIk0soBgWrG4M1m2RghKpCA
aWuAmBCkc1Gj8NeFlxyf8HQYEAGNEC1muY9meqrUIPg6YXaSBpEfoPK0Ri6T
rpSwRNdUJqwrPKGkSxIPxbq4rwRLHKh6ksb4XHXqJAS94zE7kT6LYygnG/gH
7TBFemyI2PmK7yYSQsBCqnmLOvMJVYYjdsEfRyqCUQhpidjcZZlhZAeOiwu9
eBqETmzyubwwPg3GTd1UI/K2HERCcC91BEsGlZsNNTY6OLUwBakEGRcdwV8a
mCBuJw8NFsmgpfQt74itbdFwFYnQgT9OLKQV+sou5EwHc7I95EqkbLonTz4a
MhRPDAhtBc4H5R2lVEpKYGqdcU7cV1j09lGTRaXlyGrBhS7xfNhmyzYJfRaI
94LDpsBWWr2vLVAepq8wGHKCFNKRN8HjalIaBXzTLfEFxtg8N6nIZpRDlPOI
uNcrDBpohV4gWEZ9sA/L8VUXKYUQV+px+6KMNlJNDVbqHc4AMuWpA7UGbeYI
pcCylzrmnUPTXLAbJiWCyGJ76XxUiU/HVyacKGg/FyAsgPiNm01iDUPiQ1tz
bVv1aSWjjXLwNHyVcpoGiEYEQmdJU556nmEVkBP31zHXQl9gtqa9PMWlgUUm
HEPC1qn2jDrdbu1Zg/MPnDWQcpj0C+KxqI1WRdBNsOJ08kOYsjdow3Qsw1Ih
QhIBFD4FGY45CaQBaqdjvrhSudzbp9h2vYQ2RO1stqZYNKGQFptkNhaM8CcS
y7bBcrMxbPOcbczHycEdZHZv/weZDRDJNPO9cS4BD1/Zsq0cmhsQYnazhWTD
UEq41obwDc3ACAuoQZfkOw2utaA+BRhl7WBsRIwoKABXIrPrknJlCITgmKFL
AE8O69SfDinKYkyijVvF5976u2KXEuJxkwtJWdtfxWv2VRj8aIySnDBiGOuS
jJoHirX0FzpfdYxOpJPKSL6koMKGf0h3LPUc3kcsKtBaU+CryYoty2ts0x2F
vEvfhwuychH5A08zuxK8x4ym9DT6jhRzk/i1lFpElfOfEZ9X9IGawmTeuR9H
+MmjYHAoCX6vgbge3RfUiyLMZ9NDlmFV1uL98Z1HAXl4pbj9qDy/4yE+ndnr
XbHJfLwgxgxrhLWOcAXtnJiskBLyH3AoAFtVCKnjrjkbbDXY91j/0ZaBlCC7
LKcMyAY0FNqYm6VGe7kbqXl0VsiyZDg8glaBg6ZdEJfuH8Ez6yiLecD+BNYo
vcpvl2gsPYgLcRb6cm+UMUzkzFAtp3TR4TYL+TxDCfFSTc5eVda93WqZZbIW
VkwrWnUwNoQXqcFz04gJVPMJUtGsOLjpHDTKdLWI/QeV+0Bt1zmu1m/H2pqM
fHHYsHBsgxPb3uR9RHNwe0or9PFicbd8Bgo8GiLrwOZkobMgamlv+3snHTSq
KByl/KyPTvBbM/T9CqMg7kIET01SYJmKJPrYT5TcJ6jg/XZgW8qYsex8a4Vi
CI2fGaDj1/Hko9gEcZ0KwT6WO8APhxXh15beME6kLxB17IA3TH3mhbCfSgxo
NwpSsZH19Iri3TmaGcENCz6cY3NKqONQXCSh6LRtciWnNlFPGkBlBWdEfTWU
i4hJSD+33tKnOdrS1UaqpLO+u+SOMv4GiFrATJwVDscoBBNydhyxmHU5ddf7
Ns/oKojxYmEq1tsYxcgXKu6EXl88or2QkGPW5rLHZj4H3eZvrQRYAWvI2Vhy
BQbca1ZanwEE2xhMo1jlF2S3Q6bipSEPQF/m2hu8Is/86uUpR/KCAUgkxcK1
4SRGJVRnuC5ot7la1ZujQtfXONdNYX61cWy9VRN5y4s2JgIqJBNpes2f83pD
NL2WD3q9YX/SFuh3ERLgXQX+AD/jRC9G3vfi6TmNTObBf12GeUefrTp+frwz
dSdNhxv1NHoFvSrawuhjQgwmxy9NRsb8nFO9xPoKrCiI4LqjyyA1Id8b0uXU
QfXr20EuR8isjWYoUuY4FSiQvZUQ4CZYqOJfmb3TivTJp/+49PM2GUe/lozP
1AnHc09L6naHDVKP6VN8U3WW4feX5CwmD+o9g9geFEJ8BE9SRWeA/dT84bT9
++wnv7E38D48ioeK14ChuTmw5PokyTmiVzAQjsx1mrLSkB+BRfiv17EG9ieh
8bUf0QpZ+iAgR9XtJBQMaansSOeIjU8v932TgE+89NZvPm+5iuR1PmlxmxoN
wgUQENbUni9jdAfy7+CAtGDuduyM57/9xYNSP58ckiLGwej+a0Y4An0y8h4Z
ftrslHV607SUJE0yhesVpC0hCk1NsfqT4UYU2jZzgpfSvvGgMyqLyFcsIs9s
Aa8uQA8ASotf8bIQfRWxKxdsT/0HDtGa8phf8Jh/weitcYEhG2eav39yF796
qZ7itxNOMDUyNyadgcPhUY54FGZqj/X0/Gof2iGc2w8+hEmuCdycdBqJd72H
5NzbZhRFbndRo9Tc3mDUBqzBusdvw7ejsNgeIY/zk7NI9nngQx74AhXzroOt
RAiLXzNK3hbldWZS/sAXXAEHrQuv7p0KUu/ABzzwK8mI6Dl+Fefbul6lFkHh
lTXXYif2PavLlUgKSdb3T4L3Og7E8GffcM+xAEiK2voyH2k6qWdm9q3h0Dus
Rfpq2ldxMWe6yUAQindW3T6FQK28ApKpyRZTyD4rfF0x+H0PXJAtm/STQ3hg
F01tOBJXO66XpQenfDabsiZeUiX7zcwMTVKiYBKlHOsKFnkG0CF5a9VYvXhb
a2oQ0DCoeogfd8MK1Fgd39iShMpx/wCGGhDP6RsDNzsfW/0chsvB+6tHMGeG
t59Z/EpcOa95w/4X1x4aT6VXAAA= should
still be reviewed as a best practice.
-->

  </back>
</rfc>