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

<!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  (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ace-revoked-token-notification-09" number="9770" category="std" updates="" obsoletes="" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 --> version="3" xml:lang="en">

  <front>
    <title abbrev="Notification of Revoked Tokens in ACE">Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-ace-revoked-token-notification-09"/> name="RFC" value="9770"/>
    <author initials="M." surname="Tiloca" fullname="Marco Tiloca">
      <organization>RISE AB</organization>
      <address>
        <postal>
          <street>Isafjordsgatan 22</street>
          <city>Kista</city>
          <code>16440</code>
          <country>Sweden</country>
        </postal>
        <email>marco.tiloca@ri.se</email>
      </address>
    </author>
    <author initials="F." surname="Palombini" fullname="Francesca Palombini">
      <organization>Ericsson AB</organization>
      <address>
        <postal>
          <street>Torshamnsgatan 23</street>
          <city>Kista</city>
          <code>16440</code>
          <country>Sweden</country>
        </postal>
        <email>francesca.palombini@ericsson.com</email>
      </address>
    </author>
    <author initials="S." surname="Echeverria" fullname="Sebastian Echeverria">
      <organization>CMU SEI</organization>
      <address>
        <postal>
          <street>4500 Fifth Avenue</street>
          <city>Pittsburgh, PA</city>
          <city>Pittsburgh</city><region>PA</region>
          <code>15213-2612</code>
          <country>United States of America</country>
        </postal>
        <email>secheverria@sei.cmu.edu</email>
      </address>
    </author>
    <author initials="G." surname="Lewis" fullname="Grace Lewis">
      <organization>CMU SEI</organization>
      <address>
        <postal>
          <street>4500 Fifth Avenue</street>
          <city>Pittsburgh, PA</city>
          <city>Pittsburgh</city><region>PA</region>
          <code>15213-2612</code>
          <country>United States of America</country>
        </postal>
        <email>glewis@sei.cmu.edu</email>
      </address>
    </author>
    <date year="2024" month="September" day="22"/>
    <area>Security</area>
    <workgroup>ACE Working Group</workgroup>
    <keyword>Internet-Draft</keyword> year="2025" month="April"/>
    <area>SEC</area>
    <workgroup>ace</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>
      <t>This document specifies a method of the Authentication and Authorization for Constrained  Environments (ACE) framework, which allows an authorization server to notify clients and resource servers (i.e., registered devices) about revoked access tokens. As specified in this document, the method allows clients and resource servers to access a Token Revocation List (TRL) on the authorization server by using the Constrained Application Protocol (CoAP), with the possible additional use of resource observation. Resulting (unsolicited) notifications of revoked access tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on clients and resource servers.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    Authentication and Authorization for Constrained Environments Working Group mailing list (ace@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ace/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/ace-wg/ace-revoked-token-notification"/>.</t>
    </note>

  </front>
  <middle>
    <section anchor="intro">
      <name>Introduction</name>
      <t>Authentication and Authorization for Constrained Environments (ACE) <xref target="RFC9200"/> is a framework that enforces access control on IoT Internet of Things (IoT) devices acting as resource servers Resource Servers (RSs). In order to use ACE, both clients and RSs have to register with an authorization server Authorization Server (AS) and become a registered device. devices. Once registered, a client can send a request to the AS, AS to obtain an access token for an RS. For a client to access the RS, the client must present the issued access token at the RS, which then validates it before storing it (see <xref section="5.10.1.1" sectionFormat="of" target="RFC9200"/>).</t>
      <t>Even

<!--[rfced] Please review the use of "and" before list item 5: should
     this instead be "or"?

Original:
   Even though access tokens have expiration times, there are
   circumstances by which an access token may need to be revoked before
   its expiration time, such as: (1) a registered device has been
   compromised, or is suspected of being compromised; (2) a registered
   device is decommissioned; (3) there has been a change in the ACE
   profile for a registered device; (4) there has been a change in
   access policies for a registered device; and (5) there has been a
   change in the outcome of policy evaluation for a registered device
   (e.g., if policy assessment depends on dynamic conditions in the
   execution environment, the user context, or the resource utilization).</t>
   utilization).

-->

      <t>Even though access tokens have expiration times, there are circumstances by which an access token may need to be revoked before its expiration time, such as when:</t>
      <ol spacing="normal" type="1">
	<li>a registered device has been compromised or is suspected of being compromised;</li>
	<li>a registered device is decommissioned;</li>
	<li>there has been a change in the ACE profile for a registered device;</li>
	<li>there has been a change in access policies for a registered device; and</li>
	<li>there has been a change in the outcome of policy evaluation for a registered device (e.g., if policy assessment depends on dynamic conditions in the execution environment, the user context, or the resource utilization).</li>
      </ol>
      <t>As discussed in <xref section="6.1" sectionFormat="of" target="RFC9200"/>, only client-initiated revocation is currently specified <xref target="RFC7009"/> for OAuth 2.0 <xref target="RFC6749"/>, based on the assumption that access tokens in OAuth are issued with a relatively short lifetime. However, this is not expected to be the case for constrained, intermittently connected devices, devices that need access tokens with relatively long lifetimes.</t>

<!--[rfced] Were we to expand this abbreviation, this text might be
     redundant. Please let us know if/how to update.

Original:
...used in the ACE framework for Authentication and Authorization.

As expanded, this reads as:
...used in the Authentication and Authorization for Constrained
Environments framework for Authentication and Authorization.

Original:
... described in the ACE framework for Authentication and Authorization [RFC9200]...

-->

      <t>This document specifies a method for allowing registered devices to access and possibly subscribe to a Token Revocation List (TRL) on the AS, AS in order to obtain updated information about pertaining access tokens that were revoked prior to their expiration. As specified in this document, the registered devices use the Constrained Application Protocol (CoAP) <xref target="RFC7252"/> to communicate with the AS and with one another, another and can subscribe to the TRL on the AS by using resource observation for CoAP <xref target="RFC7641"/>. Other underlying Underlying protocols other than CoAP are not prohibited from being supported in the future, if they are defined to be used in the ACE framework for Authentication and Authorization.</t>
      <t>Unlike in the case of token introspection (see <xref section="5.9" sectionFormat="of" target="RFC9200"/>), a registered device does not provide an owned access token to the AS for inquiring about its current state. Instead, registered devices simply obtain updated information about pertaining access tokens that were revoked prior to their expiration, expiration as efficiently identified by corresponding hash values.</t>
      <t>The benefits of this method are that it complements token introspection, introspection and it does not require the registered devices to support any additional endpoints (see <xref target="terminology"/>). The only additional requirements for registered devices are a request/response interaction with the AS to access and possibly subscribe to the TRL (see <xref target="sec-overview"/>), target="sec-overview"/>) and the lightweight computation of hash values to use as access token identifiers (see <xref target="sec-token-name"/>).</t>

<!--[rfced] Please confirm that our suggested edit captures your
     intent.

Original:
It is also out of scope the method by which the AS determines or is
notified of revoked access tokens, according to which the AS
consequently updates the TRL as specified in this document.

Perhaps:
The method by which the AS determines or is notified of revoked access
tokens, according to which the AS consequently updates the TRL as
specified in this document, is also out of scope.

-->

      <t>The process by which access tokens are declared revoked is out of the scope of this document. It is also out of scope the method by which the AS determines or is notified of revoked access tokens, according to which the AS consequently updates the TRL as specified in this document.</t>
      <section anchor="terminology">
        <name>Terminology</name>
        <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 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <t>Readers are expected to be familiar with the terms and concepts described in the ACE framework for Authentication and Authorization <xref target="RFC9200"/>, as well as with terms and concepts related to CBOR Web Tokens (CWTs) <xref target="RFC8392"/> and JSON Web Tokens (JWTs) <xref target="RFC7519"/>.</t>
        <t>The terminology for entities in the considered architecture is defined in OAuth 2.0 <xref target="RFC6749"/>. In particular, this includes client, resource server (RS), and authorization server (AS).</t>
        <t>Readers are also expected to be familiar with the terms and concepts related to CDDL the Concise Data Definition Language (CDDL) <xref target="RFC8610"/>, CBOR Concise Binary Object Representation (CBOR) <xref target="RFC8949"/>, JSON <xref target="RFC8259"/>, COSE CBOR Object Signing and Encryption (COSE) <xref target="RFC9052"/>, CoAP <xref target="RFC7252"/>, CoAP Observe <xref target="RFC7641"/>, and the use of hash functions to name objects as defined in <xref target="RFC6920"/>.</t>

<!--[rfced] In the following, should a reference to RFC 7252 be added
     for the direct quote?  This is the first occurrence of this text
     in an RFC.

Original:
This document does not use the CoAP definition of "endpoint", which is
"An entity participating in the CoAP protocol."

Perhaps:
This document does not use the CoAP definition of "endpoint", which is
defined in [RFC7252] as "An entity participating in the CoAP protocol."

-->

        <t>Note that the term "endpoint" is used here following its OAuth definition <xref target="RFC6749"/>, aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol."</t>
        <t>This specification also refers to uses the following terminology.</t>
        <ul terminology:</t>
        <dl spacing="normal">
          <li>
            <t>Token hash: identifier
            <dt>Token hash:</dt><dd>identifier of an access token, in binary
            format encoding. The token hash has no relation to other access
            token identifiers possibly used, such as the 'cti' (CWT ID) claim
            of CBOR Web Tokens (CWTs) <xref target="RFC8392"/>.</t>
          </li>
          <li>
            <t>Token target="RFC8392"/>.</dd>

            <dt>Token Revocation List (TRL): a (TRL):</dt><dd>a collection of token
            hashes such that the corresponding access tokens have been revoked
            but are not expired yet.</t>
          </li>
          <li>
            <t>TRL endpoint: an yet.</dd>

            <dt>TRL endpoint:</dt><dd>an endpoint at the AS with a TRL as its
            representation. The default name of the TRL endpoint in a url-path
            is '/revoke/trl'. Implementations are not required to use this name,
            name and can define their own instead.</t>
          </li>
          <li>
            <t>Registered device: a instead.</dd>

            <dt>Registered device:</dt><dd>a device registered at the AS,
            i.e., as a client, or an RS, or both. A registered device acts as
            a requester towards the TRL endpoint.</t>
          </li>
          <li>
            <t>Administrator: endpoint.</dd>

            <dt>Administrator:</dt><dd><t>an entity that is authorized to get full access
            to the TRL at the AS, AS and acting that acts as a requester towards the TRL
            endpoint. An administrator is not necessarily a registered device
            as defined above, i.e., a client requesting access tokens or an RS
            consuming access tokens.  </t>
            <t>
An
            <t>An administrator might also be authorized to perform further
            administrative operations at the AS, e.g., through a dedicated
            admin interface that is out of the scope of this document. By
            considering the token hashes retrieved from the TRL together with
            other information obtained from the AS, the administrator becomes
            able to derive additional information, e.g., the fact that
            accesses have been revoked for specific registered devices.</t>
          </li>
          <li>
            <t>Pertaining devices.</t></dd>

            <dt>Pertaining access token:  </t> token:</dt>
	    <dd>
	      <ul spacing="normal">
              <li>
                <t>With
                <li><t>With reference to an administrator, an access token
                issued by the AS.</t>
              </li>
              <li>
                <t>With AS.</t></li>
		<li><t>With reference to a registered device, an access token
		intended to be owned by that device. An access token pertains
		to a client if the AS has issued the access token for that
		client following its request. An access token pertains to an
		RS if the AS has issued the access token to be consumed by
		that RS.</t>
		</li>
              </ul>
          </li>
          <li>
            <t>Token
            </dd>

            <dt>Token hash pertaining to a requester: a requester:</dt><dd>a token hash
            corresponding to an access token pertaining to that requester,
            i.e., an administrator or a registered device.</t>
          </li>
          <li>
            <t>TRL device.</dd>

            <dt>TRL update pertaining to a requester: an requester:</dt><dd>an update to the
            TRL through which token hashes pertaining to that requester have
            been added to the TRL or removed from the TRL.</t>
          </li>
          <li>
            <t>Full query: a TRL.</dd>

            <dt>Full query:</dt><dd>a type of query to the TRL, TRL where the AS
            returns the token hashes of the revoked access tokens currently in
            the TRL and pertaining to the requester. Further details are
            specified in Sections <xref target="sec-trl-endpoint"/> target="sec-trl-endpoint" format="counter"/> and <xref target="ssec-trl-full-query"/>.</t>
          </li>
          <li>
            <t>Diff query: a
            target="ssec-trl-full-query" format="counter"/>.</dd>

            <dt>Diff query:</dt><dd>a type of query to the TRL, TRL where the AS
            returns a list of diff entries, each related to one update occurred
            to the TRL and containing a set of token hashes
            pertaining to the requester. Further details are specified in
            Sections <xref target="sec-trl-endpoint"/> target="sec-trl-endpoint" format="counter"/> and <xref target="ssec-trl-diff-query"/>.</t>
          </li>
        </ul>
            target="ssec-trl-diff-query" format="counter"/>.</dd>
        </dl>
        <t>Examples throughout this document are expressed in CBOR diagnostic notation as defined in <xref section="8" sectionFormat="of" target="RFC8949"/> and <xref section="G" sectionFormat="of" target="RFC8610"/>. Diagnostic notation comments are often used to provide a textual representation of the numeric parameter names and values.</t>

        <t>In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in <xref target="fig-cddl-model"/> of <xref target="sec-cddl-model"/>. For example, {e'full_set': [], e'cursor': 3} stands for {0: [], 2: 3}.</t>
        <t>Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in <xref target="fig-cddl-model"/> of <xref target="sec-cddl-model"/>. Finally, please delete this note.</t>
      </section>
    </section>
    <section anchor="sec-overview">
      <name>Protocol Overview</name>
      <t>This protocol defines how a CoAP-based authorization server informs clients and resource servers, i.e., registered devices, about pertaining revoked access tokens. How the relationship between a registered device and the AS is established is out of the scope of this specification.</t>
      <t>At a high level, the steps of this protocol are as follows.</t>
      <ul follows:</t>
      <ol spacing="normal">
        <li>
          <t>Upon startup, the AS creates a single TRL accessible through the TRL endpoint. At any point in time, the TRL represents the list of all revoked access tokens issued by the AS that are not expired yet.</t>
        </li>
        <li>
          <t>When a device registers at the AS, it also receives the url-path to the TRL endpoint.  </t>
          <t>
At any time after the registration procedure is finished, the registered device can send a GET request to the TRL endpoint at the AS. When doing so, it can request for: the following: the current list of pertaining revoked access tokens (see <xref target="ssec-trl-full-query"/>); target="ssec-trl-full-query"/>) or the most recent updates that occurred over the list of pertaining revoked access tokens (see <xref target="ssec-trl-diff-query"/>).  </t>
<t>

<!--[rfced] Does the following rephrase capture your intended meaning?

Original:
By doing so, the registered device effectively subscribes to the TRL,
as interested in receiving notifications about its update.

Perhaps:
By doing so, the registered device effectively subscribes to the TRL,
as the device is interested in receiving notifications about the TRL's
update.
-->

In particular, the registered device can rely on Observation for CoAP <xref target="RFC7641"/>. In such a case, the GET request sent to the TRL endpoint includes the CoAP Observe Option set to 0 (register), i.e., it is an Observation Request. By doing so, the registered device effectively subscribes to the TRL, as interested in receiving notifications about its update. Upon receiving the Observation Request, the AS adds the registered device to the list of observers of the TRL endpoint.</t>
        </li>
        <li>
          <t>When an access token is revoked, the AS adds the corresponding token hash to the TRL. Also, when a revoked access token eventually expires, the AS removes the corresponding token hash from the TRL.  </t>
          <t>
<!--[rfced] We are unable to parse "and to which the access token
     pertains".  Please rephrase.

Original:
That is, an Observe notification is sent to each registered device
subscribed to the TRL and to which the access token pertains.

-->

In either case, after updating the TRL, the AS sends Observe notifications as per <xref target="RFC7641"/>. That is, an Observe notification is sent to each registered device subscribed to the TRL and to which the access token pertains.  </t>
<t>

<!--[rfced] Please review the addition of "either" and let us know if
     this edit correctly captures your intent.

Original:
Depending on the specific subscription established through the
Observation Request, the notification provides the current
updated list of revoked access tokens in the subset of the TRL
pertaining to that device (see Section 7), or the most recent TRL
updates occurred over that list of pertaining revoked access
tokens (see Section 8).

Perhaps:
Depending on the specific subscription established through the
Observation Request, the notification provides either the current
updated list of revoked access tokens in the subset of the TRL
pertaining to that device (see Section 7) or the most recent TRL
updates that occurred over that list of pertaining revoked access
tokens (see Section 8).

-->
Depending on the specific subscription established through the Observation Request, the notification provides the current updated list of revoked access tokens in the subset of the TRL pertaining to that device (see <xref target="ssec-trl-full-query"/>), or the most recent TRL updates that occurred over that list of pertaining revoked access tokens (see <xref target="ssec-trl-diff-query"/>).  </t>
          <t>
Further Observe notifications may be sent, consistently consistent with ongoing additional observations of the TRL endpoint.</t>
        </li>
        <li>
          <t>An administrator can access and subscribe to the TRL like a registered device, device while getting the content of the whole TRL (see <xref target="ssec-trl-full-query"/>) or the most recent updates occurred to the whole TRL (see <xref target="ssec-trl-diff-query"/>).</t>
        </li>
      </ul>
      </ol>
      <t><xref target="fig-protocol-overview"/> shows a high-level overview of the service provided by this protocol. For the sake of simplicity, the example shown in the figure considers the simultaneous revocation of the three access tokens t1, t2, and t3, t3 whose corresponding token hashes are th1, th2, and th3, respectively. Consequently, the AS adds the three token hashes to the TRL at once, once and sends Observe notifications to one administrator and four registered devices. Each dotted line associated with a pair of registered devices indicates the access token that they both own.</t>
      <figure anchor="fig-protocol-overview">
        <name>Protocol Overview</name>
        <artset>
          <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="320" width="560" viewBox="0 0 560 320" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
              <path d="M 8,176 L 8,224" fill="none" stroke="black"/>
              <path d="M 16,112 L 16,168" fill="none" stroke="black"/>
              <path d="M 136,176 L 136,224" fill="none" stroke="black"/>
              <path d="M 152,176 L 152,224" fill="none" stroke="black"/>
              <path d="M 160,112 L 160,168" fill="none" stroke="black"/>
              <path d="M 168,32 L 168,64" fill="none" stroke="black"/>
              <path d="M 240,176 L 240,224" fill="none" stroke="black"/>
              <path d="M 256,176 L 256,224" fill="none" stroke="black"/>
              <path d="M 264,64 L 264,168" fill="none" stroke="black"/>
              <path d="M 344,176 L 344,224" fill="none" stroke="black"/>
              <path d="M 352,32 L 352,64" fill="none" stroke="black"/>
              <path d="M 360,176 L 360,224" fill="none" stroke="black"/>
              <path d="M 368,112 L 368,168" fill="none" stroke="black"/>
              <path d="M 448,176 L 448,224" fill="none" stroke="black"/>
              <path d="M 464,176 L 464,224" fill="none" stroke="black"/>
              <path d="M 472,112 L 472,168" fill="none" stroke="black"/>
              <path d="M 552,176 L 552,224" fill="none" stroke="black"/>
              <path d="M 168,32 L 352,32" fill="none" stroke="black"/>
              <path d="M 168,64 L 256,64" fill="none" stroke="black"/>
              <path d="M 272,64 L 352,64" fill="none" stroke="black"/>
              <path d="M 16,112 L 472,112" fill="none" stroke="black"/>
              <path d="M 8,176 L 136,176" fill="none" stroke="black"/>
              <path d="M 152,176 L 240,176" fill="none" stroke="black"/>
              <path d="M 256,176 L 344,176" fill="none" stroke="black"/>
              <path d="M 360,176 L 448,176" fill="none" stroke="black"/>
              <path d="M 464,176 L 552,176" fill="none" stroke="black"/>
              <path d="M 8,224 L 136,224" fill="none" stroke="black"/>
              <path d="M 152,224 L 240,224" fill="none" stroke="black"/>
              <path d="M 256,224 L 344,224" fill="none" stroke="black"/>
              <path d="M 360,224 L 448,224" fill="none" stroke="black"/>
              <path d="M 464,224 L 552,224" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="480,168 468,162.4 468,173.6" fill="black" transform="rotate(90,472,168)"/>
              <polygon class="arrowhead" points="376,168 364,162.4 364,173.6" fill="black" transform="rotate(90,368,168)"/>
              <polygon class="arrowhead" points="272,168 260,162.4 260,173.6" fill="black" transform="rotate(90,264,168)"/>
              <polygon class="arrowhead" points="168,168 156,162.4 156,173.6" fill="black" transform="rotate(90,160,168)"/>
              <polygon class="arrowhead" points="24,168 12,162.4 12,173.6" fill="black" transform="rotate(90,16,168)"/>
              <circle cx="264" cy="64" r="6" class="opendot" fill="white" stroke="black"/>
              <g class="text">
                <text x="232" y="52">Authorization</text>
                <text x="316" y="52">server</text>
                <text x="192" y="84">/revoke/trl</text>
                <text x="308" y="84">TRL:</text>
                <text x="384" y="84">(th1,th2,th3)</text>
                <text x="72" y="148">th1,th2,th3</text>
                <text x="200" y="148">th1,th2</text>
                <text x="288" y="148">th1</text>
                <text x="392" y="148">th3</text>
                <text x="512" y="148">th2,th3</text>
                <text x="72" y="196">Administrator</text>
                <text x="188" y="196">Client</text>
                <text x="224" y="196">1</text>
                <text x="300" y="196">Resource</text>
                <text x="396" y="196">Client</text>
                <text x="432" y="196">2</text>
                <text x="508" y="196">Resource</text>
                <text x="292" y="212">server</text>
                <text x="328" y="212">1</text>
                <text x="500" y="212">server</text>
                <text x="536" y="212">2</text>
                <text x="176" y="244">:</text>
                <text x="216" y="244">:</text>
                <text x="288" y="244">:</text>
                <text x="384" y="244">:</text>
                <text x="488" y="244">:</text>
                <text x="528" y="244">:</text>
                <text x="176" y="260">:</text>
                <text x="216" y="260">:</text>
                <text x="252" y="260">t1</text>
                <text x="288" y="260">:</text>
                <text x="384" y="260">:</text>
                <text x="436" y="260">t3</text>
                <text x="488" y="260">:</text>
                <text x="528" y="260">:</text>
                <text x="176" y="276">:</text>
                <text x="252" y="276">:........:</text>
                <text x="436" y="276">:............:</text>
                <text x="528" y="276">:</text>
                <text x="176" y="292">:</text>
                <text x="340" y="292">t2</text>
                <text x="528" y="292">:</text>
                <text x="352" y="308">:...........................................:</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="center"><![CDATA[
                    +----------------------+
                    | Authorization server |
                    +-----------o----------+
                  /revoke/trl   |   TRL: (th1,th2,th3)
                                |
 +-----------------+------------+------------+------------+
 |                 |            |            |            |
 | th1,th2,th3     | th1,th2    | th1        | th3        | th2,th3
 v                 v            v            v            v
+---------------+ +----------+ +----------+ +----------+ +----------+
| Administrator | | Client 1 | | Resource | | Client 2 | | Resource |
|               | |          | | server 1 | |          | | server 2 |
+---------------+ +----------+ +----------+ +----------+ +----------+
                     :    :        :           :            :    :
                     :    :   t1   :           :     t3     :    :
                     :    :........:           :............:    :
                     :                   t2                      :
                     :...........................................:
]]></artwork>
        </artset>
      </figure>
      <t><xref target="sec-RS-examples"/> provides examples of the protocol flow and message exchanges between the AS and a registered device.</t>
    </section>
    <section anchor="sec-issuing-access-tokens-as">
      <name>Issuing of Access Tokens at the AS</name>
      <t>An AS that supports the method defined in this document <bcp14>MUST</bcp14> adhere to the following rules when issuing an access token.</t> token:</t>
      <ul spacing="normal">
        <li>
          <t>All the intended header parameters in the access token <bcp14>MUST</bcp14> be specified within integrity-protected fields.</t>
        </li>
        <li>
          <t>If the access token is a CWT, the following applies. applies:  </t>
          <ul spacing="normal">
            <li>
              <t>Any "unprotected" field <bcp14>MUST</bcp14> be empty, i.e., its value <bcp14>MUST</bcp14> be encoded as the empty CBOR map (0xa0). This applies to: to the top-level "unprotected" field of the COSE object used for the CWT; CWT, the "unprotected" field of each element of the "signatures" array; array, and the "unprotected" field of each element of any "recipients" array (see Sections <xref target="RFC9052" section="2" sectionFormat="bare"/>, <xref target="RFC9052" section="3" sectionFormat="bare"/>, <xref target="RFC9052" section="4" sectionFormat="bare"/>, <xref target="RFC9052" section="5" sectionFormat="bare"/>, and <xref target="RFC9052" section="6" sectionFormat="bare"/> of <xref target="RFC9052"/>).</t>
            </li>
            <li>

<!--[rfced] We noticed repetition of the word "tag" in the following
     sentence.  Does this rephrase correctly capture your intent?

Original:
In turn, the resulting tagged data item MUST be tagged by using
the CWT CBOR tag with tag number 61 (see Section 6 of
[RFC8392]).

Perhaps:
In turn, the resulting data item MUST be tagged using
CWT CBOR tag number 61 (see Section 6 of [RFC8392]).
-->

              <t>Consistent with the specific COSE object used for the CWT, the corresponding tagged structure in the set COSE_Tagged_Message <bcp14>MUST</bcp14> be used (see <xref section="2" sectionFormat="of" target="RFC9052"/>). That is, the CBOR array that encodes the CWT <bcp14>MUST</bcp14> be tagged by using the COSE CBOR tag corresponding to the used COSE object. Table 1 in <xref section="2" sectionFormat="of" target="RFC9052"/> specifies the tag numbers in question.      </t>
              <t>
In turn, the resulting tagged data item <bcp14>MUST</bcp14> be tagged by using the CWT CBOR tag with tag number 61 (see <xref section="6" sectionFormat="of" target="RFC8392"/>). After that, the resulting data item <bcp14>MUST NOT</bcp14> be further tagged.      </t>
              <t>
Encoding of the tag numbers <bcp14>MUST</bcp14> be done using definite lengths, and the length of the encoded tag numbers <bcp14>MUST</bcp14> be the minimum possible length. This means that the tag number 16 is encoded as 0xd0 and not as 0xd810.      </t>
              <t>
The example in <xref target="fig-cwt-cose-encrypt0"/> shows a CWT that uses the COSE object COSE_Encrypt0 (see <xref section="5.2" sectionFormat="of" target="RFC9052"/>).</t>
            </li>
          </ul>
        </li>
        <li>
          <t>If, like for JWTs <xref target="RFC7519"/>, the access token relies on a JSON object for encoding its claims, the following applies. applies:  </t>
          <t>
Consistent with the ACE framework for Authentication and Authorization <xref target="RFC9200"/>, this document specifically considers JWTs, which are always represented using the JWS  JSON Web Signature (JWS) Compact Serialization from <xref target="RFC7515"/> or the JWE JSON Web Encryption (JWE) Compact Serialization from <xref target="RFC7516"/>. Consequently, all the header parameters are specified within integrity-protected fields.  </t>
          <t>
In case alternative access tokens were used, the following applies:  </t>
          <ul spacing="normal">
            <li>
              <t>If the access token uses the JWS JSON Compact Serialization from <xref target="RFC7515"/>, it <bcp14>MUST NOT</bcp14> include the JWS Unprotected Header.</t>
            </li>
            <li>
              <t>If the access token uses the JWE JSON Compact Serialization from <xref target="RFC7516"/>, it <bcp14>MUST NOT</bcp14> include the JWE Shared Unprotected Header and it <bcp14>MUST NOT</bcp14> include the "header" member in any of the elements of the "recipients" array.</t>
            </li>
          </ul>
        </li>
      </ul>
      <figure anchor="fig-cwt-cose-encrypt0">
        <name>Example of CWT Using COSE_Encrypt0</name>
        <artwork align="left"><![CDATA[
        <sourcecode><![CDATA[
/ CWT CBOR tag / 61(
  / COSE_Encrypt0 CBOR tag / 16(
    / COSE_Encrypt0 object / [
      / protected /   h'a3010a044c53796d6d65747269633132
                        38054d99a0d7846e762c49ffe8a63e0b',
      / unprotected / {},
      / ciphertext /  h'b918a11fd81e438b7f973d9e2e119bcb
                        22424ba0f38a80f27562f400ee1d0d6c
                        0fdb559c02421fd384fc2ebe22d70713
                        78b0ea7428fff157444d45f7e6afcda1
                        aae5f6495830c58627087fc5b4974f31
                        9a8707a635dd643b'
    ]
  )
)
]]></artwork>
]]></sourcecode>
      </figure>
      <t><xref target="sec-seccons-token-manipulation"/> discusses how adhering to the rules above neutralizes an attack against the RS, RS where an active adversary can induce the RS to compute a token hash different from the correct one.</t>
    </section>
    <section anchor="sec-token-name">

<!--[rfced] Much of Section 4 describes terminology.  Should a pointer
     to this section be added to the Terminology section?

Perhaps:
See Section 4 for further terminology used throughout that section.

-->

      <name>Token Hash</name>
      <t>This section specifies how token hashes are computed.</t>
      <t>First, <xref target="sec-token-hash-input-motivation"/> provides the motivation for the used construction.</t>
      <t>Building on that, the value used as input to compute a token hash is defined in <xref target="sec-token-hash-input-c-as"/> for the client and the AS, AS and in <xref target="sec-token-hash-input-rs"/> for the RS. Finally, <xref target="sec-token-hash-output"/> defines how such an input is used for computing the token hash.</t>
      <t>The process outlined below refers to the base64url encoding and decoding without padding (see <xref section="5" sectionFormat="of" target="RFC4648"/>), target="RFC4648"/>) and denotes as "binary representation" of a text string the corresponding UTF-8 encoding <xref target="RFC3629"/>, which is the implied charset used in JSON (see <xref section="8.1" sectionFormat="of" target="RFC8259"/>).</t>
      <t>Consistent with <xref section="3.4" sectionFormat="of" target="RFC8949"/>, the term "tag" is used for the entire CBOR data item consisting of both a tag number and the tag content: the tag content is the CBOR data item that is being tagged.</t>
      <t>Also, "tagged access token" is used to denote nested CBOR tags (possibly a single one), with the innermost tag content being a CWT.</t>
      <section anchor="sec-token-hash-input-motivation">
        <name>Motivation for the Used Construction</name>

<!--[rfced] Does this rephrase capture your intended meaning?

Original:
An access token can have one among different formats.

Perhaps:
There are different formats an access token can have.
	-->

        <t>An access token can have one among different formats. The most expected formats are CWT <xref target="RFC8392"/> and JWT <xref target="RFC7519"/>, with the former being the default format to use in the ACE framework for Authentication and Authorization (see <xref section="3" sectionFormat="of" target="RFC9200"/>). While access tokens are opaque to clients, an RS is aware of whether access tokens that are issued for it to consume are either CWTs or JWTs.</t>
        <section anchor="issuing-of-the-access-token-to-the-client">
          <name>Issuing of the Access Token to the Client</name>
          <t>There are two possible encodings that the AS can use for the AS-to-Client response (see <xref section="5.8.2" sectionFormat="of" target="RFC9200"/>), target="RFC9200"/>) where the issued access token is included and provided to the requester client. The RS may not be aware of which encoding is used for that response to that particular requester client.</t>
          <ul spacing="normal">
            <li>
<!--[rfced] We note that the sub-bullets in Section 4.1.1 reverse
     order (i.e., the first bullet has CWT and then JWT mentioned in
     the sub-bullets and the second bullet lists JWT and then CWT in
     the sub-bullets).  Please confirm that this is intentional or let
     us know if you'd like them to appear in the same order in both
     places.-->

              <t>One way method of encoding relies on CBOR, which is required if CoAP is used (see <xref section="5" sectionFormat="of" target="RFC9200"/>) and is recommended otherwise (see <xref section="3" sectionFormat="of" target="RFC9200"/>). That is, the AS-to-Client response has media-type "application/ace+cbor".  </t>
              <t>
This implies that, within the CBOR map specified as message payload, the parameter 'access_token' is a CBOR data item of type CBOR byte string and with a value of BYTES. In particular:  </t>
              <ul spacing="normal">
                <li>
                  <t>If the access token is a CWT, then BYTES is the binary representation of the CWT (i.e., of the CBOR array that encodes the untagged CWT) or of a tagged access token with the CWT as the innermost tag content.</t>
                </li>
                <li>
                  <t>If the access token is a JWT, then BYTES is the binary representation of the JWT (i.e., of the text string that encodes the JWT).</t>
                </li>
              </ul>
            </li>
            <li>
              <t>An alternative way method of encoding relies on JSON. That is, the AS-to-Client response has media-type "application/ace+json".  </t>
              <t>
This implies that, within the JSON object specified as message payload, the parameter 'access_token' has as a value a text string TEXT. In particular:  </t>
              <ul spacing="normal">
                <li>
                  <t>If the access token is a JWT, then TEXT is the text string that encodes the JWT.</t>
                </li>
                <li>
                  <t>If the access token is a CWT, then TEXT is the base64url-encoded text string of BYTES, which is the binary representation of the CWT (i.e., of the CBOR array that encodes the untagged CWT) or of a tagged access token with the CWT as the innermost tag content.</t>
                </li>
              </ul>
            </li>
          </ul>
        </section>
        <section anchor="sec-token-hash-input-motivation-rs">
          <name>Provisioning of Access Tokens to the RS</name>
          <t>In accordance with the used transport profile of ACE (e.g., <xref target="RFC9202"/>, <xref target="RFC9203"/>, <xref target="RFC9431"/>), the RS receives a piece of token-related information hereafter denoted as TOKEN_INFO.</t>
          <t>In particular:</t>
          <ul spacing="normal">
            <li>

<!--[rfced] When "tagged" appears in parentheses, should the reader
     assume this means "either tagged or not tagged"?  For example:

Original:
That is, TOKEN_INFO is the binary representation of the (tagged)
access token.

Perhaps:
That is, TOKEN_INFO is the binary representation of the tagged
access token (whether or not it is tagged).
-->

              <t>If the AS-to-Client response was encoded in CBOR, then TOKEN_INFO is the value of the CBOR byte string conveyed by the 'access_token' parameter of that response. That is, TOKEN_INFO is the binary representation of the (tagged) access token.</t>
            </li>
            <li>
              <t>If the AS-to-Client response was encoded in JSON and the access token is a JWT, then TOKEN_INFO is the binary representation of the text string conveyed by the 'access_token' parameter of that response. That is, TOKEN_INFO is the binary representation of the access token.</t>
            </li>
            <li>
              <t>If the AS-to-Client response was encoded in JSON and the access token is a CWT, then TOKEN_INFO is the binary representation of the base64url-encoded text string that encodes the binary representation of the (tagged) access token. That is, TOKEN_INFO is the binary representation of the base64url-encoded text string conveyed by the 'access_token' parameter.</t>
            </li>
          </ul>
          <t>The following overviews how the above specifically applies to the existing transport profiles of ACE.</t> ACE:</t>
          <ul spacing="normal">
            <li>
              <t>The (tagged) access token can be uploaded to the RS by means of a POST request to the /authz-info endpoint (see <xref section="5.10.1" sectionFormat="of" target="RFC9200"/>), using a CoAP Content-Format or HTTP media-type that reflects the format of the access token, if available (e.g., "application/cwt" for CWTs), or "application/octet-stream" otherwise. When doing so (e.g., like in <xref target="RFC9202"/>), TOKEN_INFO is the payload of the POST request.</t>
            </li>
            <li>
              <t>The (tagged) access token can be uploaded to the RS by means of a POST request to the /authz-info endpoint, using the media-type "application/ace+cbor". When doing so (e.g., like in <xref target="RFC9203"/>), TOKEN_INFO is the value of the CBOR byte string conveyed by the 'access_token' parameter, within the CBOR map specified as payload of the POST request.</t>
            </li>
            <li>
              <t>The (tagged) access token can be uploaded to the RS during a DTLS session establishment, e.g., like it is defined in <xref section="3.2.2" sectionFormat="of" target="RFC9202"/>. When doing so, TOKEN_INFO is the value of the 'psk_identity' field of the ClientKeyExchange message (when using DTLS 1.2 <xref target="RFC6347"/>), target="RFC6347"/>) or of the 'identity' field of a PSKIdentity, within the PreSharedKeyExtension of a ClientHello message (when using DTLS 1.3 <xref target="RFC9147"/>).</t>
            </li>
            <li>
              <t>The (tagged) access token can be uploaded to the RS within the MQTT CONNECT packet, e.g., like it is defined in <xref section="2.2.4.1" sectionFormat="of" target="RFC9431"/>. When doing so, TOKEN_INFO is specified within the 'Authentication Data' field of the MQTT CONNECT packet, following the property identifier 22 (0x16) and the token length.</t>
            </li>
          </ul>
        </section>
        <section anchor="design-rationale">
          <name>Design Rationale</name>
          <t>Considering the possible variants discussed above, it must always be ensured that the same HASH_INPUT value is used as input for generating the token hash of a given access token, by the AS that has issued the access token and by the registered devices to which the access token pertains (both client and RS).</t>
          <t>This is achieved by building HASH_INPUT according to the content of the 'access_token' parameter in the AS-to-Client responses, since responses because that is what all among the AS, the client, and the RS are all able to see.</t>
        </section>
      </section>
      <section anchor="sec-token-hash-input-c-as">
        <name>Hash Input on the Client and the AS</name>
        <t>The client and the AS consider the content of the 'access_token' parameter in the AS-to-Client response, where in which the (tagged) access token is included and provided to the requester client.</t>
        <t>The following defines how the client and the AS determine the HASH_INPUT value to use as input for computing the token hash of the conveyed access token, depending on the AS-to-Client response being encoded in CBOR (see <xref target="sec-token-hash-input-c-as-cbor"/>) or in JSON (see <xref target="sec-token-hash-input-c-as-json"/>).</t>
        <t>Once determined HASH_INPUT, the HASH_INPUT is determined, the client and the AS use it to compute the token hash of the conveyed access token as defined in <xref target="sec-token-hash-output"/>.</t>
        <section anchor="sec-token-hash-input-c-as-cbor">
          <name>AS-to-Client Response Encoded in CBOR</name>
          <t>If the AS-to-Client response is encoded in CBOR, then HASH_INPUT is defined as follows:</t>
          <ul spacing="normal">
            <li>
              <t>BYTES denotes the value of the CBOR byte string conveyed in the parameter 'access_token'.  </t>

<!--[rfced] Please confirm that commas should not separate these
     values in curly brackets:

Original:
  With reference to the example in Figure 3, BYTES is the bytes
      {0xd8 0x3d 0xd0 ... 0x64 0x3b}.
-->

              <t>
With reference to the example in <xref target="fig-as-response-cbor"/>, BYTES is the bytes {0xd8 0x3d 0xd0 ... 0x64 0x3b}.  </t>
              <t>
Note that BYTES is the binary representation of the tagged access token if this is a CWT (as per <xref target="sec-issuing-access-tokens-as"/>), target="sec-issuing-access-tokens-as"/>) or of the access token if this is a JWT.</t>
            </li>
            <li>
              <t>HASH_INPUT_TEXT is the base64url-encoded text string that encodes BYTES.</t>
            </li>
            <li>
              <t>HASH_INPUT is the binary representation of HASH_INPUT_TEXT.</t>
            </li>
          </ul>
          <figure anchor="fig-as-response-cbor">
            <name>Example of AS-to-Client CoAP response using Response Using CBOR</name>
            <artwork align="left"><![CDATA[
            <sourcecode type="coap"><![CDATA[
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Max-Age: 85800
Payload:
{
   / access_token / 1 : h'd83dd0835820a3010a044c53796d6d
                          6574726963313238054d99a0d7846e
                          762c49ffe8a63e0ba05858b918a11f
                          d81e438b7f973d9e2e119bcb22424b
                          a0f38a80f27562f400ee1d0d6c0fdb
                          559c02421fd384fc2ebe22d7071378
                          b0ea7428fff157444d45f7e6afcda1
                          aae5f6495830c58627087fc5b4974f
                          319a8707a635dd643b',
   / token_type /  34 : 2 / PoP /,
   / expires_in /   2 : 86400,
   / ace_profile / 38 : 1 / coap_dtls /,
   / (remainder of the response omitted for brevity) /
}
]]></artwork>
]]></sourcecode>
          </figure>
        </section>
        <section anchor="sec-token-hash-input-c-as-json">
          <name>AS-to-Client Response Encoded in JSON</name>
          <t>If the AS-to-Client response is encoded in JSON, then HASH_INPUT is the binary representation of the text string conveyed by the 'access_token' parameter.</t>
          <t>With reference to the example in <xref target="fig-as-response-json"/>, HASH_INPUT is the binary representation of "eyJh...YFiA". When showing the access token, <xref target="fig-as-response-json"/> uses line breaks for display purposes only.</t>
          <t>Note that:</t>
          <ul spacing="normal">
            <li>
              <t>If the access token is a JWT, then HASH_INPUT is the binary representation of the JWT.</t>
            </li>
            <li>

              <t>If the access token is a CWT, then HASH_INPUT is the binary representation of a base64url-encoded text string, which encodes the binary representation of a tagged access token with the CWT as the innermost tag content (as per <xref target="sec-issuing-access-tokens-as"/>).</t>
            </li>
          </ul>
          <figure anchor="fig-as-response-json">
            <name>Example of AS-to-Client HTTP response using Response Using JSON</name>
            <artwork align="left"><![CDATA[
            <sourcecode type="json"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/ace+json
Cache-Control: no-store
Pragma: no-cache
Payload:
{
   "access_token" : "eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJB
                     MTI4Q0JDLUhTMjU2In0.
                     QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8
                     qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM
                     oNfABIPJaZm0HaA415sv3aeuBWnD8J-U
                     i7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG
                     TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvW
                     n_hXV1BNMHzUjPyYwEsRhDhzjAD26ima
                     sOTsgruobpYGoQcXUwFDn7moXPRfDE8-
                     NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52
                     YCitxoQVPzjbl7WBuB7AohdBoZOdZ24W
                     lN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a
                     1rZgN5TiysnmzTROF869lQ.
                     AxY8DCtDaGlsbGljb3RoZQ.
                     MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeW
                     nDYvpIAeZ72deHxz3roJDXQyhxx0wKaM
                     HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7
                     sln1Eu9g3J8.
                     fiK51VwhsxJ-siBMR-YFiA",
   "token_type"   : "pop",
   "expires_in"   : 86400,
   "ace_profile"  : "1"
}
]]></artwork>
]]></sourcecode>
          </figure>
        </section>
      </section>
      <section anchor="sec-token-hash-input-rs">
        <name>HASH_INPUT on the RS</name>
        <t>The following defines how the RS determines the HASH_INPUT value to use as input for computing the token hash of an access token, depending on the RS using either CWTs (see <xref target="sec-token-hash-input-rs-cwt"/>) or JWTs (see <xref target="sec-token-hash-input-rs-jwt"/>).</t>
        <section anchor="sec-token-hash-input-rs-cwt">
          <name>Access Tokens as CWTs</name>
          <t>If the RS expects access tokens to be CWTs, then the RS performs the following steps.</t> steps:</t>
          <ol spacing="normal" type="1"><li>
              <t>The RS receives the token-related information TOKEN_INFO, in accordance with what is specified by the used profile of ACE (see <xref target="sec-token-hash-input-motivation-rs"/>).</t>
            </li>
            <li>
              <t>The RS assumes that the client received the access token in an AS-to-Client response encoded in CBOR (see <xref target="sec-token-hash-input-c-as-cbor"/>). Hence, the RS assumes TOKEN_INFO to be the binary representation of the tagged access token with the CWT as the innermost tag content (as per <xref target="sec-issuing-access-tokens-as"/>).</t>
            </li>
            <li>
              <t>The RS verifies the access token as per <xref section="5.10.1.1" sectionFormat="of" target="RFC9200"/>. If the verification fails, then the RS does not discard the access token yet, and yet; instead, it instead moves to step 4.  </t> 4.</t>
              <t>
Otherwise, the RS stores the access token and computes the corresponding token hash, hash as defined in <xref target="sec-token-hash-output"/>. In particular, the RS considers HASH_INPUT_TEXT as the base64url-encoded text string that encodes TOKEN_INFO. Then, HASH_INPUT is the binary representation of HASH_INPUT_TEXT.  </t>
              <t>
After that, the RS stores the computed token hash as associated with the access token, and then token; then, it terminates this algorithm.</t>
            </li>
            <li>
              <t>The RS assumes that the client received the access token in an AS-to-Client response encoded in JSON (see <xref target="sec-token-hash-input-c-as-json"/>). Hence, the RS assumes TOKEN_INFO to be the binary representation of HASH_INPUT_TEXT. In turn, HASH_INPUT_TEXT is the base64url-encoded text string that encodes the binary representation of the tagged access token with the CWT as the innermost tag content (as per <xref target="sec-issuing-access-tokens-as"/>).</t>
            </li>
            <li>
              <t>The RS performs the base64url decoding of HASH_INPUT_TEXT, HASH_INPUT_TEXT and considers the result as to be the binary representation of the tagged access token.</t>
            </li>
            <li>
              <t>The RS verifies the access token as per <xref section="5.10.1.1" sectionFormat="of" target="RFC9200"/>. If the verification fails, then the RS terminates this algorithm.  </t>
              <t>
Otherwise, the RS stores the access token and computes the corresponding token hash, hash as defined in <xref target="sec-token-hash-output"/>. In particular, HASH_INPUT is TOKEN_INFO.  </t>
              <t>
After that, the RS stores the computed token hash as associated with the access token.</t>
            </li>
          </ol>
        </section>
        <section anchor="sec-token-hash-input-rs-jwt">
          <name>Access Tokens as JWTs</name>
          <t>If the RS expects access tokens to be JWTs, then the RS performs the following steps.</t> steps:</t>
          <ol spacing="normal" type="1"><li>
              <t>The RS receives the token-related information TOKEN_INFO, in accordance with what is specified by the used profile of ACE (see <xref target="sec-token-hash-input-motivation-rs"/>).</t>
            </li>
            <li>
              <t>The RS verifies the access token as per <xref section="5.10.1.1" sectionFormat="of" target="RFC9200"/>. If the verification fails, then the RS terminates this algorithm. Otherwise, the RS stores the access token.</t>
            </li>
            <li>
              <t>The RS computes a first token hash associated with the access token, token as defined in <xref target="sec-token-hash-output"/>.  </t>
              <t>
In particular, the RS assumes that the client received the access token in an AS-to-Client response encoded in JSON (see <xref target="sec-token-hash-input-c-as-json"/>). Hence, HASH_INPUT is TOKEN_INFO.  </t>
              <t>
After that, the RS stores the computed token hash as associated with the access token.</t>
            </li>
            <li>
              <t>The RS computes a second token hash associated with the access token, token as defined in <xref target="sec-token-hash-output"/>.  </t>
              <t>
In particular, the RS assumes that the client received the access token in an AS-to-Client response encoded in CBOR (see <xref target="sec-token-hash-input-c-as-cbor"/>). Hence, HASH_INPUT is the binary representation of HASH_INPUT_TEXT, which which, in turn turn, is the base64url-encoded text string that encodes TOKEN_INFO.  </t>
              <t>
After that, the RS stores the computed token hash as associated with the access token.</t>
            </li>
          </ol>

          <t>The RS skips step 3 only if it is certain that all its pertaining access tokens are provided to any client by means of AS-to-Client responses encoded as CBOR messages. Otherwise, the RS <bcp14>MUST</bcp14> perform step 3.</t>
          <t>The RS skips step 4 only if it is certain that all its pertaining access tokens are provided to any client by means of AS-to-Client responses encoded as JSON messages. Otherwise, the RS <bcp14>MUST</bcp14> perform step 4.</t>
          <t>If the RS performs both step steps 3 and step 4 above, then the RS <bcp14>MUST</bcp14> store, maintain, and rely on both token hashes as associated with the access token, consistent with what is specified in <xref target="sec-handling-token-hashes"/>.</t>
          <t><xref target="sec-seccons-two-hashes-jwt"/> discusses how computing and storing both token hashes neutralizes an attack against the RS, where a dishonest client can induce the RS to compute a token hash different from the correct one.</t>
        </section>
      </section>
      <section anchor="sec-token-hash-output">
        <name>Computing the Token Hash</name>
        <t>Once determined HASH_INPUT is determined as defined in Sections <xref target="sec-token-hash-input-c-as"/> target="sec-token-hash-input-c-as" format="counter"/> and <xref target="sec-token-hash-input-rs"/>, target="sec-token-hash-input-rs" format="counter"/>, a hash value of HASH_INPUT is generated as per <xref section="6" sectionFormat="of" target="RFC6920"/>. The resulting output in binary format is used as the token hash. Note that the used binary format embeds the identifier of the used hash function, function in the first byte of the computed token hash.</t>

        <t>The specifically used specific hash function used <bcp14>MUST</bcp14> be collision-resistant collision resistant on byte-strings, byte strings and <bcp14>MUST</bcp14> be selected from the "Named Information Hash Algorithm" Registry Algorithm Registry" <xref target="Named.Information.Hash.Algorithm"/>. target="IANA.Hash.Algorithms"/>. Consistent with the compliance requirements in <xref section="2" sectionFormat="of" target="RFC6920"/>, the hash function sha-256 as specified in <xref target="SHA-256"/> is mandatory to implement.</t>
        <t>The AS specifies the used hash function to registered devices during their registration procedure (see <xref target="sec-registration"/>).</t>
      </section>
    </section>
    <section anchor="sec-trl-resource">
      <name>Token Revocation List (TRL)</name>
      <t>Upon startup, the AS creates a single Token Revocation List (TRL), (TRL) encoded as a CBOR array.</t>
      <t>Each

<!--[rfced] These sentences do not parse.  Please review "with value
     the token hash" in particular.

Original:
   Each element of the array is a CBOR byte string, with value the token
   hash of an access token.

Original:
Each element of the array is a CBOR byte string, with value the
token hash of an access token such that: it pertained to the
requester; and it was removed from the TRL during the update
associated with the diff entry.
-->

      <t>Each element of the array is a CBOR byte string with value the token hash of an access token. The CBOR array <bcp14>MUST</bcp14> be treated as a set, i.e., the order of its elements has no meaning.</t>
      <t>The TRL is initialized as empty, i.e., its initial content <bcp14>MUST</bcp14> be the empty CBOR array. The TRL is accessible through the TRL endpoint at the AS.</t>
      <section anchor="ssec-trl-update">
        <name>Update of the TRL</name>
        <t>The AS updates the TRL in the following two cases.</t> cases:</t>
        <ul spacing="normal">
          <li>
            <t>When a non-expired access token is revoked, the token hash of the access token is added to the TRL. That is, a CBOR byte string with the token hash as its value is added to the CBOR array encoding the TRL.</t>
          </li>
          <li>
            <t>When a revoked access token expires, the token hash of the access token is removed from the TRL. That is, the CBOR byte string with the token hash as its value is removed from the CBOR array encoding the TRL.</t>
          </li>
        </ul>
        <t>The AS <bcp14>MAY</bcp14> perform a single update to the TRL such that one or more token hashes are added or removed at once. For example, this can be the case if multiple access tokens are revoked or expire at the same time, time or within an acceptably narrow time window.</t> frame.</t>
      </section>
    </section>
    <section anchor="sec-trl-endpoint">
      <name>The TRL Endpoint</name>

<!--[rfced] The double prepositions (between and towards) make this
     text hard to parse.  How may we rephrase?

Original:
Consistent with Section 6.5 of [RFC9200], all communications between
a requester towards the TRL endpoint and the AS MUST be encrypted, as
well as integrity and replay protected.

-->
      <t>Consistent with <xref section="6.5" sectionFormat="of" target="RFC9200"/>, all communications between a requester towards the TRL endpoint and the AS <bcp14>MUST</bcp14> be encrypted, as well as integrity and replay protected. Furthermore, responses from the AS to the requester <bcp14>MUST</bcp14> be bound to the corresponding requests.</t>
      <t>Following a request to the TRL endpoint, the corresponding, corresponding success response messages sent by the AS use Content-Format "application/ace-trl+cbor". Their payload is formatted as a CBOR map, and the CBOR values used to abbreviate the parameters included therein are defined in <xref target="trl-registry-parameters"/>.</t>
      <t>The AS <bcp14>MUST</bcp14> implement measures to prevent access to the TRL endpoint by entities other than registered devices and authorized administrators (see <xref target="sec-registration"/>).</t>
      <t>The TRL endpoint supports only the GET method, and allows two types of queries of the TRL.</t>
      <ul TRL:</t>
      <ol spacing="normal">
        <li>
          <t>Full query: the AS returns the token hashes of the revoked access tokens currently in the TRL and pertaining to the requester.  </t>
          <t>
The AS <bcp14>MUST</bcp14> support this type of query. The processing of a full query and the related response format are defined in <xref target="ssec-trl-full-query"/>.</t>
        </li>
        <li>
          <t>Diff query: the AS returns a list of diff entries. Each diff entry is related to one update occurred to the TRL, and it contains a set of token hashes pertaining to the requester. In particular, all such token hashes were added to the TRL or removed from the TRL at the update related to the diff entry in question.  </t>
          <t>
The AS <bcp14>MAY</bcp14> support this type of query. In such a case, the AS maintains the history of updates to the TRL as defined in <xref target="sec-trl-endpoint-supporting-diff-queries"/>. The processing of a diff query and the related response format are defined in <xref target="ssec-trl-diff-query"/>.</t>
        </li>
      </ul>
      </ol>
      <t>If it supports diff queries, the AS <bcp14>MAY</bcp14> additionally support its "Cursor" extension, which has two benefits. First, the benefits:</t>
      <ol>
	<li>The AS can avoid excessively long messages when several diff entries have to be transferred, transferred by delivering several diff query responses, each containing one adjacent subset of diff entries at a time. Second, a time.</li>
	<li>A requester can retrieve diff entries associated with TRL updates that, even if not the most recent ones, occurred after a TRL update associated with a diff entry indicated as a reference point.</t> point.</li></ol>
      <t>If it supports the "Cursor" extension, the AS stores additional information when maintaining the history of updates to the TRL, TRL as defined in <xref target="sec-trl-endpoint-supporting-cursor"/>. Also, the processing of full query requests and diff query requests, as well as the related response format, are further extended as defined in <xref target="sec-using-cursor"/>.</t>
      <t><xref target="sec-trl-parameteters"/> provides an aggregated overview of the local supportive parameters that the AS internally uses at its TRL endpoint, endpoint when supporting diff queries and the "Cursor" extension.</t>
      <section anchor="sec-error-responses">
        <name>Error Responses with Problem Details</name>
        <t>Some error responses from the TRL endpoint at the AS can convey error-specific information according to the problem-details format defined in <xref target="RFC9290"/>. Such error responses <bcp14>MUST</bcp14> have Content-Format set to "application/concise-problem-details+cbor". The payload of these error responses <bcp14>MUST</bcp14> be a CBOR map specifying a Concise Problem Details data item (see <xref section="2" sectionFormat="of" target="RFC9290"/>). The CBOR map is formatted as follows.</t> follows:</t>
        <ul spacing="normal">
          <li>
            <t>It <bcp14>MUST</bcp14> include the Custom Problem Detail entry 'ace-trl-error' registered in <xref target="iana-custom-problem-details"/> of this document. This entry is formatted as a CBOR map, which includes the following fields.  </t> fields:</t>
            <ul spacing="normal">
              <li>
                <t>The field 'error-id' field <bcp14>MUST</bcp14> be present. The map key used for this field is the CBOR unsigned integer with a value of 0. The value of this field is a CBOR integer specifying the error that occurred at the AS. This value is taken from the 'Value' column of the "ACE Token Revocation List Errors" registry defined in <xref target="iana-token-revocation-list-errors"/> of this document.</t>
              </li>
              <li>
                <t>The field 'cursor' field <bcp14>MAY</bcp14> be present. The map key used for this field is the CBOR unsigned integer with a value of 1. The value of this field is a CBOR unsigned integer or the CBOR simple value <tt>null</tt> (0xf6). The use of this field is defined in <xref target="sec-trl-endpoint-query-parameters"/>.</t>
              </li>
            </ul>
            <t>
The CDDL notation <xref target="RFC8610"/> of the 'ace-trl-error' entry is given below.</t>
          </li>
        </ul> below:</t>

        <sourcecode type="CDDL"><![CDATA[
   ace-trl-error = {
       0: int,        ; error-id
     ? 1: uint / null ; cursor
   }
]]></sourcecode>
        <ul spacing="normal">
          </li>

          <li>
            <t>It <bcp14>MAY</bcp14> include further Standard Problem Detail entries or Custom Problem Detail entries (see <xref target="RFC9290"/>).  </t>
            <t>
In particular, it can include the Standard Problem Detail entry 'detail' (map key -2), whose value is a CBOR text string that specifies a human-readable, human-readable diagnostic description of the error that occurred at the AS. The diagnostic text is intended for software engineers as well as for device and network operators, operators in order to aid in debugging and provide context for possible intervention. The diagnostic message <bcp14>SHOULD</bcp14> be logged by the AS. The 'detail' entry is unlikely to be relevant in an unattended setup where human intervention is not expected.</t>
          </li>
        </ul>
        <t>An example of an error response using the problem-details format is shown in <xref target="fig-example-error-response"/>.</t>
        <figure anchor="fig-example-error-response">
          <name>Example of Error Response with Problem Details</name>
          <artwork><![CDATA[
          <sourcecode type=""><![CDATA[
Header: Bad Request (Code=4.00)
Content-Format: application/concise-problem-details+cbor
Payload:
{
  / title /     -1: "Invalid parameter value",
  / detail /    -2: "Invalid value for 'cursor': -53",
  / ace-trl-error / e'ace-trl-error': {
    / error-id / 0: 0 / "Invalid parameter value" /,
    / cursor /   1: 42
  }
}
]]></artwork>
]]></sourcecode>
        </figure>
        <t>The problem-details format in general and the Custom Problem Detail entry 'ace-trl-error' in particular are <bcp14>OPTIONAL</bcp14> to support for registered devices. A registered device supporting the entry 'ace-trl-error' and that is able to understand the specified error may use that information to determine what actions to take next.</t>
      </section>
      <section anchor="sec-trl-endpoint-supporting-diff-queries">
        <name>Supporting Diff Queries</name>
        <t>If the AS supports diff queries, it is able to transfer a list of diff entries, each of which is related to one update that occurred to the TRL (see <xref target="sec-trl-endpoint"/>). That is, when replying to a diff query performed by a requester, the AS specifies the diff entries related to the most recent TRL updates pertaining to the requester.</t>
        <t>The following defines how the AS builds and maintains an ordered list of diff entries, for each registered device and administrator, hereafter referred to as requesters. "requesters". In particular, a requester's diff entry associated with a TRL update contains a set of token hashes pertaining to that requester, each of which were was added to the TRL or removed from the TRL at that update.</t>
        <t>The AS defines the single, single constant positive integer MAX_N &gt;= 1. For each requester, the AS maintains an update updated collection of maximum MAX_N series items, each of which is a diff entry. For each requester, the AS <bcp14>MUST</bcp14> keep track of the MAX_N most recent TRL updates pertaining to the requester. If the AS supports diff queries, the AS <bcp14>MUST</bcp14> provide requesters with the value of MAX_N, MAX_N upon their registration (see <xref target="sec-registration"/>).</t>
        <t>The series of items in the update collection <bcp14>MUST</bcp14> be strictly ordered in a chronological fashion. chronologically ordered. That is, at any point in time, the current first series item is would be the one least recently added to the update collection and still retained by the AS, while AS; the current last series item is would be the one most recently added to the update collection. The particular method used to achieve this is implementation-specific.</t> implementation specific.</t>
        <t>Each time the TRL changes, the AS performs the following operations for each requester.</t> requester:</t>
        <ol spacing="normal" type="1"><li>
            <t>The AS considers the subset of the TRL pertaining to that requester. If the TRL subset is not affected by this TRL update, the AS stops the processing for that requester. Otherwise, the AS moves to step 2.</t>
          </li>

<!--[rfced] Please review the following text and let us know what
     "trl_patch" names?  Is this the name of the sets?  The token
     hashes?

Original:

   2.  The AS creates two sets "trl_patch" of token hashes, i.e., one
   "removed" set and one "added" set, as related to this TRL update.

Perhaps:

   2.  The AS creates two sets of "trl_patch" token hashes, i.e., one
   "removed" set and one "added" set, as related to this TRL update.

-->

          <li>
            <t>The AS creates two sets "trl_patch" of token hashes, i.e., one  "removed" set and one "added" set, as related to this TRL update.</t>
          </li>
          <li>
            <t>The AS fills the two sets with the token hashes of the removed and added access tokens, respectively, from/to the TRL subset considered at step 1.</t>
          </li>
          <li>
            <t>The AS creates a new series item, which item that includes the two sets from step 3.</t>
          </li>
          <li>
            <t>If the update collection associated with the requester currently includes MAX_N series items, the AS <bcp14>MUST</bcp14> delete the oldest series item in the update collection.</t>
          </li>
          <li>
            <t>The AS adds the series item to the update collection associated with the requester, requester as the last (most recent) one.</t> entry.</t>
          </li>
        </ol>
        <section anchor="sec-trl-endpoint-supporting-cursor">
          <name>Supporting the "Cursor" Extension</name>
          <t>If it supports the "Cursor" extension for diff queries, the AS performs also performs the following actions.</t> actions:</t>
          <t>The AS defines the single, single constant unsigned integer MAX_INDEX &lt;= ((2^64) - 1), where "^" is the exponentiation operator. The value of MAX_INDEX is <bcp14>REQUIRED</bcp14> to be at least (MAX_N - 1), 1) and is <bcp14>RECOMMENDED</bcp14> to be at least ((2^32) - 1). MAX_INDEX <bcp14>SHOULD</bcp14> be orders of magnitude greater than MAX_N.</t>
          <t>The following applies separately for each requester's update collection.</t> collection:</t>
          <ul spacing="normal">
            <li>
              <t>Each series item X in the update collection is also associated with an unsigned integer 'index', whose minimum value is 0 and whose maximum value is MAX_INDEX. The first series item ever added to the update collection <bcp14>MUST</bcp14> have an 'index' with a value of 0.  </t>
              <t>
If i_X is the value of 'index' associated with a series item X, then the following series item Y will take 'index' with a value of i_Y = (i_X + 1) % (MAX_INDEX + 1). That is, after having added a series item whose associated 'index' has a value of MAX_INDEX, the next added series item will result in a wrap-around wraparound of the 'index' value, and value; thus, it will thus take an 'index' with a value of 0.  </t>
              <t>
For example, assuming MAX_N = 3, the values of 'index' in the update collection chronologically evolve as follows, as new series items are added and old series items are deleted. deleted:  </t>
              <ul spacing="normal">
                <li>
                  <t>...</t>
                </li>
                <li>
                  <t>(i_A = MAX_INDEX - 2, i_B = MAX_INDEX - 1, i_C = MAX_INDEX)</t>
                </li>
                <li>
                  <t>(i_B = MAX_INDEX - 1, i_C = MAX_INDEX, i_D = 0)</t>
                </li>
                <li>
                  <t>(i_C = MAX_INDEX, i_D = 0, i_E = 1)</t>
                </li>
                <li>
                  <t>(i_D = 0, i_E = 1, i_F = 2)</t>
                </li>
                <li>
                  <t>...</t>
                </li>
              </ul>
            </li>
            <li>
              <t>The unsigned integer 'last_index' is also defined, with minimum value 0 and maximum value MAX_INDEX.  </t>
              <t>
If the update collection is empty (i.e., no series items have been added yet), the value of 'last_index' is not defined. If the update collection is not empty, 'last_index' has the value of 'index' currently associated with the last series item in the update collection.  </t>
              <t>
That is, after having added V series items to the update collection, the last and most recently added series item has an 'index' with a value of 'last_index' = (V - 1) % (MAX_INDEX + 1).  </t>
              <t>
As long as a wrap-around wraparound of the 'index' value has not occurred, the value of 'last_index' is the absolute counter of series items added to that update collection, minus 1.</t>
            </li>
          </ul>
          <t>When processing a diff query using the "Cursor" extension, the values of 'index' are used as cursor information, as defined in <xref target="sec-using-cursor-diff-query-response"/>.</t>
          <t>For each requester's update collection, the AS also defines a constant, constant positive integer MAX_DIFF_BATCH &lt;= MAX_N, whose value specifies the maximum number of diff entries to be included in a single diff query response. The specific value <bcp14>MAY</bcp14> depend on the specific registered device or administrator associated with the update collection in question. If supporting the "Cursor" extension, the AS <bcp14>MUST</bcp14> provide registered devices and administrators with the corresponding value of MAX_DIFF_BATCH, MAX_DIFF_BATCH upon their registration (see <xref target="sec-registration"/>).</t>
        </section>
      </section>
      <section anchor="sec-trl-endpoint-query-parameters">
        <name>Query Parameters</name>
        <t>A GET request to the TRL endpoint can include the following query parameters. The AS <bcp14>MUST</bcp14> silently ignore unknown query parameters.</t>
        <ul spacing="normal">
          <li>
            <t>'diff': if included, it indicates to perform a diff query of the TRL (see <xref target="ssec-trl-diff-query"/>). Its value <bcp14>MUST</bcp14> be either:  </t>
            <ul spacing="normal">
              <li>
                <t>the integer 0, indicating that a (notification) response should include as many diff entries as the AS can provide in the response; or</t>
              </li>
              <li>
                <t>a positive integer strictly greater than 0, indicating the maximum number of diff entries that a (notification) response should include.</t>
              </li>
            </ul>
            <t>
If the AS does not support diff queries, it ignores the 'diff' query parameter when present in the GET request, request and proceeds like when processing a full query of the TRL (see <xref target="ssec-trl-full-query"/>).  </t>
            <t>
Otherwise, the AS <bcp14>MUST</bcp14> return a 4.00 (Bad Request) response in case the 'diff' query parameter of the GET request specifies a value that is neither 0 nor a positive integer, irrespective of the presence of the 'cursor' parameter and its value (see below). The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" set to "application/concise-problem-details+cbor", and its payload is formatted as defined in <xref target="sec-error-responses"/>. Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error-id' field <bcp14>MUST</bcp14> be set to 0 ("Invalid parameter value"), and the field 'cursor' field <bcp14>MUST NOT</bcp14> be present.</t>
          </li>
          <li>
            <t>'cursor': if included, it indicates to perform a diff query of the TRL together with the "Cursor" extension, as defined in <xref target="sec-using-cursor-diff-query-response"/>. Its value <bcp14>MUST</bcp14> be either 0 or a positive integer. If the 'cursor' query parameter is included, then the 'diff' query parameter <bcp14>MUST</bcp14> also be included.  </t>
            <t>
If included, the 'cursor' query parameter specifies an unsigned integer value that was provided by the AS in a previous response from the TRL endpoint (see Sections <xref target="sec-using-cursor-full-query-response"/>, target="sec-using-cursor-full-query-response" format="counter"/>, <xref target="sec-using-cursor-diff-query-response-no-cursor"/>, target="sec-using-cursor-diff-query-response-no-cursor" format="counter"/>, and <xref target="sec-using-cursor-diff-query-response-cursor"/>). target="sec-using-cursor-diff-query-response-cursor" format="counter"/>).  </t>
            <t>
	    If the AS does not support the "Cursor" extension, it ignores the 'cursor' query parameter when present in the GET request. In such a case, the AS proceeds as specified elsewhere in this document, i.e.: i) it that is:</t>
	    <ol>
	      <li>it performs a diff query of the TRL (see <xref target="ssec-trl-diff-query"/>), if it supports diff queries and the 'diff' query parameter is present in the GET request; or ii) it or</li>
	      <li>it performs a full query of the TRL (see <xref target="ssec-trl-full-query"/>) otherwise.  </t> target="ssec-trl-full-query"/>).  </li></ol>
            <t>
If the AS supports both diff queries and the "Cursor" extension, and the GET request specifies the 'cursor' query parameter, then the AS <bcp14>MUST</bcp14> return a 4.00 (Bad Request) response in case any of the conditions below holds.  </t>
            <t>
The 4.00 (Bad Request) response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" set to "application/concise-problem-details+cbor", and its payload is formatted as defined in <xref target="sec-error-responses"/>.  </t>
            <ul spacing="normal">
              <li>
                <t>The GET request does not specify the 'diff' query parameter, irrespective of the value of the 'cursor' parameter.      </t>
                <t>
Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error-id' field <bcp14>MUST</bcp14> be set to 1 ("Invalid set of parameters"), and the field 'cursor' field <bcp14>MUST NOT</bcp14> be present.</t>
              </li>
              <li>
                <t>The 'cursor' query parameter has a value that is neither 0 nor a positive integer, or integer; otherwise, it has a value strictly greater than MAX_INDEX (see <xref target="sec-trl-endpoint-supporting-cursor"/>).      </t>
                <t>
		Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error-id' field <bcp14>MUST</bcp14> be set to 0 ("Invalid parameter value"). The entry 'ace-trl-error' <bcp14>MUST</bcp14> include the field 'cursor', 'cursor' field, whose value is either: the either:</t>
		<ul>
		  <li>the CBOR simple value <tt>null</tt> (0xf6), if the update collection associated with the requester is empty; or the or</li>
		  <li>the corresponding current value of 'last_index' otherwise.</t> 'last_index'.</li></ul>
              </li>
              <li>
                <t>All
<!--[rfced] Please clarify what "it" refers to in the following:

Original:

      -  All of the following hold: the update collection associated
         with the requester is not empty; no wrap-around of its 'index'
         value has occurred; and the 'cursor' query parameter has a
         value strictly greater than the current 'last_index' on the
         update collection (see Section 6.2.1).

-->

                <t>All of the following hold: the update collection associated with the requester is not empty; no wraparound of its 'index' value has occurred; and the 'cursor' query parameter has a value strictly greater than the current 'last_index' on the update collection (see <xref target="sec-trl-endpoint-supporting-cursor"/>).      </t>
                <t>
Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error-id' field <bcp14>MUST</bcp14> be set to 2 ("Out of bound cursor value"), and the field 'cursor' field <bcp14>MUST NOT</bcp14> be present.</t>
              </li>
            </ul>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="ssec-trl-full-query">
      <name>Full Query of the TRL</name>
      <t>In order to produce a (notification) response to a GET request asking for a full query of the TRL, the AS performs the following actions.</t> actions:</t>
      <ol spacing="normal" type="1"><li>
          <t>From the TRL, the AS builds a set of HASHES such that:  </t>
          <ul spacing="normal">
            <li>
              <t>If the requester is a registered device, HASHES specifies the token hashes currently in the TRL and associated with the access tokens pertaining to that registered device. The AS can always use the authenticated identity of the registered device to perform the necessary filtering on the TRL content.</t>
            </li>
            <li>
              <t>If the requester is an administrator, HASHES specifies all the token hashes currently in the TRL.</t>
            </li>
          </ul>
        </li>
        <li>
          <t>The AS sends a 2.05 (Content) response to the requester. The response <bcp14>MUST</bcp14> have Content-Format set to "application/ace-trl+cbor". The payload of the response is a CBOR map, which <bcp14>MUST</bcp14> be formatted as follows.  </t>
          <ul spacing="normal">
            <li>
              <t>The 'full_set' parameter <bcp14>MUST</bcp14> be included and specifies a CBOR array 'full_set_value'. Each element of 'full_set_value' is a CBOR byte string, string with a value of one of the token hashes from the set HASHES. If the set HASHES is empty, the 'full_set' parameter specifies the empty CBOR array.      </t>
              <t>
The CBOR array <bcp14>MUST</bcp14> be treated as a set, i.e., the order of its elements has no meaning.</t>
            </li>
            <li>
              <t>The 'cursor' parameter <bcp14>MUST</bcp14> be included if the AS supports both diff queries and the related "Cursor" extension (see Sections <xref target="sec-trl-endpoint-supporting-diff-queries"/> target="sec-trl-endpoint-supporting-diff-queries" format="counter"/> and <xref target="sec-trl-endpoint-supporting-cursor"/>). target="sec-trl-endpoint-supporting-cursor" format="counter"/>). Its value is set as specified in <xref target="sec-using-cursor-full-query-response"/>, target="sec-using-cursor-full-query-response"/> and provides the requester with information for performing a follow-up diff query using the "Cursor" extension (see <xref target="sec-using-cursor-diff-query-response"/>).      </t>
              <t>
If the AS does not support both diff queries and the "Cursor" extension, this parameter <bcp14>MUST NOT</bcp14> be included. In case the requester does not support both diff queries and the "Cursor" extension, it <bcp14>MUST</bcp14> silently ignore the 'cursor' parameter if present.</t>
            </li>
          </ul>
        </li>
      </ol>
      <t><xref target="cddl-full"/> provides the CDDL definition <xref target="RFC8610"/> of the CBOR array 'full_set_value' specified in the response from the AS, AS as the value of the 'full_set' parameter.</t>
      <figure anchor="cddl-full">
        <name>CDDL definition Definition of 'full_set_value'</name>
        <artwork type="CDDL" align="left"><![CDATA[
        <sourcecode type="CDDL"><![CDATA[
token_hash = bytes
full_set_value = [* token_hash]
]]></artwork>
]]></sourcecode>
      </figure>
      <t><xref target="response-full"/> shows an example response from the AS, AS following a full query request to the TRL endpoint. In this example, the AS does not support diff queries nor the "Cursor" extension, extension; hence the 'cursor' parameter is not included in the payload of the response. Also, full token hashes are omitted for brevity.</t>
      <figure anchor="response-full">
        <name>Example of response following Response Following a full query request Full Query Request to the TRL endpoint</name>
        <artwork align="left"><![CDATA[ Endpoint</name>
        <sourcecode type=""><![CDATA[
Header: Content (Code=2.05)
Content-Format: application/ace-trl+cbor
Payload:
{
   e'full_set' : [
     h'01fa51cc...4819', / elided for brevity /
     h'01748190...223d'  / elided for brevity /
   ]
}
]]></artwork>
]]></sourcecode>
      </figure>
    </section>
    <section anchor="ssec-trl-diff-query">
      <name>Diff Query of the TRL</name>
      <t>In order to produce a (notification) response to a GET request asking for a diff query of the TRL, the AS performs the following actions.</t> actions:</t>
      <t>Note that, if the AS supports both diff queries and the related "Cursor" extension, the steps 3 and 4 defined below are extended as defined in <xref target="sec-using-cursor-diff-query-response"/>.</t>
      <ol spacing="normal" type="1"><li>
          <t>The AS defines the positive integer NUM as follows. If follows: if the value N specified in the 'diff' query parameter in the GET request is equal to 0 or greater than the pre-defined predefined positive integer MAX_N (see <xref target="sec-trl-endpoint-supporting-diff-queries"/>), then NUM takes the value of MAX_N. Otherwise, NUM takes N.</t>
        </li>
        <li>
          <t>The AS determines U = min(NUM, SIZE), where SIZE &lt;= MAX_N. In particular, SIZE is the number of diff entries currently stored in the requester's update collection.</t>
        </li>
        <li>
          <t>The AS prepares U diff entries. If U is equal to 0 (e.g., because SIZE is equal to 0 at step 2), then no diff entries are prepared.  </t>
          <t>
The prepared diff entries are related to the U most recent TRL updates pertaining to the requester, as maintained in the update collection for that requester (see <xref target="sec-trl-endpoint-supporting-diff-queries"/>). In particular, the first diff entry refers to the most recent of such updates, the second diff entry refers to the second from last of such updates, and so on.  </t>
          <t>
	  Each diff entry is a CBOR array 'diff_entry', which includes the following two elements.  </t>
          <ul spacing="normal">
            <li>
              <t>The first elements:</t>

<!--[rfced] This sentence doesn't parse.  Please rephrase especially
     the part with "with value the token hash of an access token".
     Note similar text is in both bullets under number 3 in Section 8.
     Please let us know if the same fix may be applied in both places
     or if different changes are required.

Original:
Each element of the array is a CBOR byte string, with value the token
hash of an access token such that: it pertained to the requester; and
it was removed from the TRL during the update associated with the diff
entry.

-->

          <ol type="a" spacing="normal">
            <li>
              <t>A 'trl_patch' set of token hashes, hashes encoded as a CBOR array 'removed'. Each element of the array is a CBOR byte string, string with value the token hash of an access token such that: that it pertained pertains to the requester; requester and it was removed from the TRL during the update associated with the diff entry.</t>
            </li>
            <li>
              <t>The second element is a
              <t>A 'trl_patch' set of token hashes, hashes encoded as a CBOR array 'added'. Each element of the array is a CBOR byte string, string with value the token hash of an access token such that: that it pertains to the requester; requester and it was added to the TRL during the update associated with the diff entry.</t>
            </li>
          </ul>
          </ol>
          <t>
The CBOR arrays 'removed' and 'added' <bcp14>MUST</bcp14> be treated as sets, i.e., the order of their elements has no meaning.</t>
        </li>
        <li>
          <t>The AS prepares a 2.05 (Content) response for the requester. The response <bcp14>MUST</bcp14> have Content-Format set to "application/ace-trl+cbor". The payload of the response is a CBOR map, which <bcp14>MUST</bcp14> be formatted as follows.  </t> follows:</t>
          <ul spacing="normal">

            <li>
              <t>The 'diff_set' parameter <bcp14>MUST</bcp14> be present and specifies a CBOR array 'diff_set_value' of U elements. Each element of 'diff_set_value' specifies one of the CBOR arrays 'diff_entry' prepared above as a diff entry. Note that U might have a value 0, of 0; in which case this case, 'diff_set_value' is the empty CBOR array.      </t>
              <t>
Within 'diff_set_value', the  any 'diff_entry' CBOR arrays 'diff_entry' <bcp14>MUST</bcp14> be sorted to reflect the corresponding updates to the TRL in reverse chronological order. That is, the first 'diff_entry' element of 'diff_set_value' relates to the most recent TRL update pertaining to the requester. The second 'diff_entry' element relates to the second from last second-to-last most recent TRL update pertaining to the requester, and so on.</t>
            </li>
            <li>
              <t>The 'cursor' parameter and the 'more' parameter <bcp14>MUST</bcp14> be included if the AS supports both diff queries and the related "Cursor" extension (see <xref target="sec-trl-endpoint-supporting-cursor"/>). Their values are set as specified in <xref target="sec-using-cursor-diff-query-response"/>, target="sec-using-cursor-diff-query-response"/> and provide the requester with information for performing a follow-up query of the TRL (see <xref target="sec-using-cursor-diff-query-response"/>).      </t>
              <t>
In case the AS supports diff queries but not the "Cursor" extension, these parameters <bcp14>MUST NOT</bcp14> be included. In case the requester supports diff queries but not included, and the "Cursor" extension, it AS <bcp14>MUST</bcp14> silently ignore the 'cursor' parameter and the 'more' parameter if present.</t>
            </li>
          </ul>
        </li>
      </ol>
      <t><xref target="cddl-diff"/> provides the CDDL definition <xref target="RFC8610"/> of the CBOR array 'diff_set_value' specified in the response from the AS, as the value of the 'diff_set' parameter.</t>
      <figure anchor="cddl-diff">
        <name>CDDL definition Definition of 'diff_set_value'</name>
        <artwork type="CDDL" align="left"><![CDATA[
        <sourcecode type="CDDL"><![CDATA[
   token_hash = bytes
   trl_patch = [* token_hash]
   diff_entry = [removed: trl_patch, added: trl_patch]
   diff_set_value = [* diff_entry]
]]></artwork>
]]></sourcecode>
      </figure>
      <t><xref target="response-diff"/> shows an example response from the AS, AS following a diff query request to the TRL endpoint, where U = 3 diff entries are specified. In this example, the AS does not support the "Cursor" extension, hence extension; hence, the 'cursor' parameter and the 'more' parameter are not included in the payload of the response. Also, full token hashes are omitted for brevity.</t>
      <figure anchor="response-diff">
        <name>Example of response following Response Following a diff query request Diff Query Request to the TRL endpoint</name>
        <artwork align="left"><![CDATA[ Endpoint</name>
        <sourcecode type=""><![CDATA[
Header: Content (Code=2.05)
Content-Format: application/ace-trl+cbor
Payload:
{
   e'diff_set' : [
     [
       [ h'01fa51cc...0f6a', / elided for brevity /
         h'01748190...8bce'  / elided for brevity /
       ],
       [ h'01cdf1ca...563d', / elided for brevity /
         h'01be41a6...a057'  / elided for brevity /
       ]
     ],
     [
       [ h'0144dd12...77bc', / elided for brevity /
         h'01231fff...a2ce'  / elided for brevity /
       ],
       []
     ],
     [
       [],
       [ h'01ca986f...ffc1', / elided for brevity /
         h'01fe1a2b...def0'  / elided for brevity /
       ]
     ]
   ]
}
]]></artwork>
]]></sourcecode>
      </figure>
      <t><xref target="sec-series-pattern"/> discusses how performing a diff query of the TRL is is, in fact fact, a usage example of the Series Transfer Pattern defined in <xref target="I-D.bormann-t2trg-stp"/>.</t>
    </section>
    <section anchor="sec-using-cursor">
      <name>Response Messages when Using the "Cursor" Extension</name>
      <t>If the AS supports both diff queries and the "Cursor" extension, it composes a response to a full query request or diff query request as defined in Sections <xref target="sec-using-cursor-full-query-response"/> target="sec-using-cursor-full-query-response" format="counter"/> and <xref target="sec-using-cursor-diff-query-response"/>, target="sec-using-cursor-diff-query-response" format="counter"/>, respectively.</t>
      <t>The exact format of the response depends on the on:</t>
      <ul>
	<li>the request being a full query or diff query request, on the request,</li>
	<li>the presence of the 'diff' and 'cursor' query parameters and their values in the diff query request, and on the and</li>
	<li>the current status of the update collection associated with the requester.</t> requester.</li></ul>
      <t>Error handling and the possible resulting error responses are as defined in <xref target="sec-trl-endpoint-query-parameters"/>.</t>
      <section anchor="sec-using-cursor-full-query-response">
        <name>Response to Full Query</name>
        <t>When processing a full query request to the TRL endpoint, the AS composes a response as defined in <xref target="ssec-trl-full-query"/>.</t>
        <t>In particular, the 'cursor' parameter included in the CBOR map carried in the response payload specifies either the CBOR simple value <tt>null</tt> (0xf6) or a CBOR unsigned integer.</t>
        <t>The 'cursor' parameter <bcp14>MUST</bcp14> specify the CBOR simple value <tt>null</tt> (0xf6) in case there are currently no TRL updates pertaining to the requester, i.e., the update collection for that requester is empty. This is the case from when the requester registers at the AS until the first update pertaining to that requester occurs to the TRL.</t>

<!--[rfced] Please confirm our update to use the antecedent instead of
     "This" for clarity.

Original:
Otherwise, the 'cursor' parameter MUST specify a CBOR unsigned
integer.  This MUST take the 'index' value of the last series item in
the update collection associated with the requester (see Section
6.2.1), as corresponding to the most recent TRL update pertaining to
the requester.

Perhaps:
Otherwise, the 'cursor' parameter MUST specify a CBOR unsigned
integer.  This integer MUST take the 'index' value of the last series item in
the update collection associated with the requester (see Section
6.2.1) as corresponding to the most recent TRL update pertaining to
the requester.

-->

        <t>Otherwise, the 'cursor' parameter <bcp14>MUST</bcp14> specify a CBOR unsigned integer. This <bcp14>MUST</bcp14> take the 'index' value of the last series item in the update collection associated with the requester (see <xref target="sec-trl-endpoint-supporting-cursor"/>), target="sec-trl-endpoint-supporting-cursor"/>) as corresponding to the most recent TRL update pertaining to the requester. Such In fact, such a value is in fact the current value of 'last_index' for the update collection associated with the requester.</t>
      </section>
      <section anchor="sec-using-cursor-diff-query-response">
        <name>Response to Diff Query</name>
        <t>When processing a diff query request to the TRL endpoint, the AS composes a response as defined in the following.</t> following subsections.</t>
        <section anchor="sec-using-cursor-diff-query-response-empty">
          <name>Empty Collection</name>
          <t>If the update collection associated with the requester has no elements, the AS returns a 2.05 (Content) response. The response <bcp14>MUST</bcp14> have Content-Format "application/ace-trl+cbor" set to "application/ace-trl+cbor", and its payload <bcp14>MUST</bcp14> be a CBOR map formatted as follows.</t> follows:</t>

<!--[rfced] *ADs - please review the following sentences that may lead
     to two interpretations of what the BCP 14 language applies to
     (due to the use of "and").  If the suggested text is not
     accurate, we suggest breaking up these sentences or rewording for
     clarity.  Note that some of the following sentences appear in
     more than one location.

Original:

   *  The 'diff_set' parameter MUST be included and specifies the empty
      CBOR array.

   *  The 'cursor' parameter MUST be included and specifies the CBOR
      simple value null (0xf6).

   *  The 'more' parameter MUST be included and specifies the CBOR
      simple value false (0xf4).

Perhaps:

   *  The 'diff_set' parameter MUST be included and MUST specify the empty
      CBOR array.

   *  The 'cursor' parameter MUST be included and MUST specify the CBOR
      simple value null (0xf6).

   *  The 'more' parameter MUST be included and MUST specify the CBOR
   simple value false (0xf4).

Original:
       *  The 'full_set' parameter MUST be included and specifies a CBOR
       array 'full_set_value'.

Perhaps:
       *  The 'full_set' parameter MUST be included and MUST specify a CBOR
       array 'full_set_value'.

Original:
       *  The 'diff_set' parameter MUST be present and specifies a CBOR
       array 'diff_set_value' of U elements.

Perhaps:
       *  The 'diff_set' parameter MUST be present and MUST specify a CBOR
       array 'diff_set_value' of U elements.

Original:
       *  The 'diff_set' parameter MUST be present and specifies a CBOR
       array 'diff_set_value' of U elements.

Perhaps:
       *  The 'diff_set' parameter MUST be present and MUST specify a CBOR
       array 'diff_set_value' of U elements.

Original:

      -  The 'cursor' parameter MUST be present and specifies a CBOR
      unsigned integer.

Perhaps:
      -  The 'cursor' parameter MUST be present and MUST specify a CBOR
      unsigned integer.

Original:
      -  The 'more' parameter MUST be present and MUST specify the CBOR
         simple value false (0xf4) if U <= MAX_DIFF_BATCH, or the CBOR
         simple value true (0xf5) otherwise.

Perhaps:
      - The 'more' parameter MUST be present and MUST specify the CBOR
      simple value false (0xf4) if U <= MAX_DIFF_BATCH; otherwise, it
      MUST specify the CBOR simple value true (0xf5).

Original:
         o  The 'more' parameter MUST be present and MUST specify the
            CBOR simple value false (0xf4) if SUB_U <= MAX_DIFF_BATCH,
            or the CBOR simple value true (0xf5) otherwise.

Perhaps:
         o  The 'more' parameter MUST be present and MUST specify the
            CBOR simple value false (0xf4) if SUB_U <= MAX_DIFF_BATCH;
            otherwise, it MUST specify the CBOR simple value true (0xf5).

-->

          <ul spacing="normal">
            <li>
              <t>The 'diff_set' parameter <bcp14>MUST</bcp14> be included and specifies the empty CBOR array.</t>
            </li>
            <li>
              <t>The 'cursor' parameter <bcp14>MUST</bcp14> be included and specifies the CBOR simple value <tt>null</tt> (0xf6).</t>
            </li>
            <li>
              <t>The 'more' parameter <bcp14>MUST</bcp14> be included and specifies the CBOR simple value <tt>false</tt> (0xf4).</t>
            </li>
          </ul>
          <t>Note that the above applies when the update collection associated with the requester has no elements, regardless of whether or not the 'cursor' query parameter is included or not in the diff query request, request and irrespective of the specified unsigned integer value if present.</t>
        </section>
        <section anchor="sec-using-cursor-diff-query-response-no-cursor">
          <name>Cursor Not Specified in the Diff Query Request</name>
          <t>If the update collection associated with the requester is not empty and the diff query request does not include the 'cursor' query parameter, the AS performs the actions defined in <xref target="ssec-trl-diff-query"/>, with the following differences.</t> differences:</t>
          <ul spacing="normal">
            <li>
              <t>At step 3, the AS considers the value MAX_DIFF_BATCH (see <xref target="sec-trl-endpoint-supporting-cursor"/>), target="sec-trl-endpoint-supporting-cursor"/>) and prepares L = min(U, MAX_DIFF_BATCH) diff entries.  </t>
              <t>
If U &lt;= MAX_DIFF_BATCH, the prepared diff entries are the last series items in the update collection associated with the requester, corresponding to the L most recent TRL updates pertaining to the requester.  </t>
              <t>
If U &gt; MAX_DIFF_BATCH, the prepared diff entries are the eldest of the last U series items in the update collection associated with the requester, as corresponding to the first L of the U most recent TRL updates pertaining to the requester.</t>
            </li>
            <li>
              <t>At step 4, the CBOR map to carry in the payload of the 2.05 (Content) response <bcp14>MUST</bcp14> be formatted as follows. follows:  </t>
              <ul spacing="normal">
                <li>
                  <t>The 'diff_set' parameter <bcp14>MUST</bcp14> be present and specifies a CBOR array 'diff_set_value' of L elements. Each element of 'diff_set_value' specifies one of the CBOR arrays 'diff_entry' prepared as a diff entry.</t>
                </li>
                <li>
                  <t>The 'cursor' parameter <bcp14>MUST</bcp14> be present and specifies a CBOR unsigned integer. This <bcp14>MUST</bcp14> take the 'index' value of the series item of the update collection included as first diff entry in the 'diff_set_value' CBOR array, which is specified by the 'diff_set' parameter. That is, the 'cursor' parameter takes the 'index' value of the series item in the update collection corresponding to the most recent TRL update pertaining to the requester and returned in this diff query response.      </t>
                  <t>
Note that the 'cursor' parameter takes the same 'index' value of the last series item in the update collection when U &lt;= MAX_DIFF_BATCH.</t>
                </li>
                <li>
                  <t>The 'more' parameter <bcp14>MUST</bcp14> be present and <bcp14>MUST</bcp14> specify the CBOR simple value <tt>false</tt> (0xf4) if U &lt;= MAX_DIFF_BATCH, MAX_DIFF_BATCH or the CBOR simple value <tt>true</tt> (0xf5) otherwise.</t>
                </li>
              </ul>
            </li>
          </ul>
          <t>If the 'more' parameter in the payload of the received 2.05 (Content) response has a value of <tt>true</tt>, the requester can send a follow-up diff query request including the 'cursor' query parameter, parameter with the same value of the 'cursor' parameter specified in this diff query response. As defined in <xref target="sec-using-cursor-diff-query-response-cursor"/>, this would result in the AS transferring the following subset of series items as diff entries, thus resuming from where interrupted in the previous transfer.</t>
        </section>
        <section anchor="sec-using-cursor-diff-query-response-cursor">
          <name>Cursor Specified in the Diff Query Request</name>
          <t>If the update collection associated with the requester is not empty and the diff query request includes the 'cursor' query parameter with value P, the AS proceeds as follows, depending on which of the following two cases hold.</t>
          <ul spacing="normal"> hold:</t>
          <ol spacing="normal" type='Case %C:'>
            <li>
              <t>Case A - The
              <t>The series item X with 'index' having value P and the series item Y with 'index' having value (P + 1) % (MAX_INDEX + 1) are both not found in the update collection associated with the requester. This occurs when the item Y (and possibly further ones after it) has been previously removed from the update collection for that requester (see step 5 at <xref target="sec-trl-endpoint-supporting-diff-queries"/>).  </t>
              <t>
In this case, the AS returns a 2.05 (Content) response. The response <bcp14>MUST</bcp14> have Content-Format "application/ace-trl+cbor" set to "application/ace-trl+cbor", and its payload <bcp14>MUST</bcp14> be a CBOR map formatted as follows. follows:  </t>
              <ul spacing="normal">
                <li>
                  <t>The 'diff_set' parameter <bcp14>MUST</bcp14> be included and specifies the empty CBOR array.</t>
                </li>
                <li>
                  <t>The 'cursor' parameter <bcp14>MUST</bcp14> be included and specifies the CBOR simple value <tt>null</tt> (0xf6).</t>
                </li>
                <li>
                  <t>The 'more' parameter <bcp14>MUST</bcp14> be included and specifies the CBOR simple value <tt>true</tt> (0xf5).</t>
                </li>
              </ul>
              <t>
With the combination ('cursor', 'more') = (<tt>null</tt>, <tt>true</tt>), the AS is indicating that the update collection is is, in fact fact, not empty, but that one or more series items have been lost due to their removal. These include the item with 'index' value (P + 1) % (MAX_INDEX + 1), 1) that the requester wished to obtain as the first one following the specified reference point with 'index' value P.  </t>
              <t>
When receiving this diff query response, the requester <bcp14>SHOULD</bcp14> send a new full query request to the AS. A successful response provides the requester with the full, full current pertaining subset of the TRL, TRL as well as with a valid value of the 'cursor' parameter (see <xref target="sec-using-cursor-full-query-response"/>) to be possibly be, possibly, used as query parameter in a following diff query request.</t>
            </li>
            <li>
              <t>Case B - The
              <t>The series item X with 'index' having value P is found in the update collection associated with the requester; requester or the series item X is not found and the series item Y with 'index' having value (P + 1) % (MAX_INDEX + 1) is found in the update collection associated with the requester.  </t>
              <t>
In this case, the AS performs the actions defined in <xref target="ssec-trl-diff-query"/>, target="ssec-trl-diff-query"/> with the following differences.  </t> differences:</t>
              <ul spacing="normal">
                <li>
                  <t>At step 3, the AS considers the value MAX_DIFF_BATCH (see <xref target="sec-trl-endpoint-supporting-cursor"/>), target="sec-trl-endpoint-supporting-cursor"/>) and prepares L = min(SUB_U, MAX_DIFF_BATCH) diff entries, where SUB_U = min(NUM, SUB_SIZE), SUB_SIZE) and SUB_SIZE is the number of series items in the update collection starting from and including the series item added immediately after X. If L is equal to 0 (e.g., because SUB_U is equal to 0), then no diff entries are prepared.      </t>
                  <t>
If SUB_U &lt;= MAX_DIFF_BATCH, the prepared diff entries are the last series items in the update collection associated with the requester, corresponding to the L most recent TRL updates pertaining to the requester.      </t>
                  <t>
If SUB_U &gt; MAX_DIFF_BATCH, the prepared diff entries are the eldest of the last SUB_U series items in the update collection associated with the requester, corresponding to the first L of the SUB_U most recent TRL updates pertaining to the requester.</t>
                </li>
                <li>
                  <t>At step 4, the CBOR map to carry in the payload of the 2.05 (Content) response <bcp14>MUST</bcp14> be formatted as follows. follows:      </t>
                  <ul spacing="normal">
                    <li>
                      <t>The 'diff_set' parameter <bcp14>MUST</bcp14> be present and specifies a CBOR array 'diff_set_value' of L elements. Each element of 'diff_set_value' specifies one of the CBOR arrays 'diff_entry' prepared as a diff entry. Note that L might have value 0, in which case 'diff_set_value' is the empty CBOR array.</t>
                    </li>
                    <li>
                      <t>The 'cursor' parameter <bcp14>MUST</bcp14> be present and <bcp14>MUST</bcp14> specify a CBOR unsigned integer. In particular:          </t>
                      <ul spacing="normal">
                        <li>
                          <t>If L is equal to 0, i.e., the series item X is the last one in the update collection, then the 'cursor' parameter <bcp14>MUST</bcp14> take the same 'index' value of the last series item in the update collection. Such In fact, such a value is in fact the current value of 'last_index' for the update collection.</t>
                        </li>
                        <li>
                          <t>If L is different than 0, then the 'cursor' parameter <bcp14>MUST</bcp14> take the 'index' value of the series element of the update collection included as first diff entry in the 'diff_set' CBOR array. That is, the 'cursor' parameter takes the 'index' value of the series item in the update collection corresponding to the most recent TRL update pertaining to the requester and returned in this diff query response.</t>
                        </li>
                      </ul>
                      <t>
Note that the 'cursor' parameter takes the same 'index' value of the last series item in the update collection when SUB_U &lt;= MAX_DIFF_BATCH.</t>
                    </li>
                    <li>
                      <t>The 'more' parameter <bcp14>MUST</bcp14> be present and <bcp14>MUST</bcp14> specify the CBOR simple value <tt>false</tt> (0xf4) if SUB_U &lt;= MAX_DIFF_BATCH, or the CBOR simple value <tt>true</tt> (0xf5) otherwise.</t>
                    </li>
                  </ul>
                </li>
              </ul>
              <t>
If the 'more' parameter in the payload of the received 2.05 (Content) response has value <tt>true</tt>, the requester can send a follow-up diff query request including the 'cursor' query parameter, parameter with the same value of the 'cursor' parameter specified in this diff query response. This would result in the AS transferring the following subset of series items as diff entries, thus thus, resuming from where interrupted in the previous transfer.</t>
            </li>
          </ul>
          </ol>
        </section>
      </section>
    </section>
    <section anchor="sec-registration">
      <name>Registration at the Authorization Server</name>
      <t>During the registration process at the AS, an administrator or a registered device receives the following information as part of the registration response.</t> response:</t>
      <ul spacing="normal">
        <li>
          <t>The url-path to the TRL endpoint at the AS.</t>
        </li>
        <li>
          <t>The hash function used to compute token hashes. This is specified by identifying an entry in the "Named Information Hash Algorithm" Registry Algorithm Registry" <xref target="Named.Information.Hash.Algorithm"/>. target="IANA.Hash.Algorithms"/>. The specific means for this is outside the scope of this document.</t>
        </li>
        <li>
          <t>A positive integer MAX_N, if the AS supports diff queries of the TRL (see Sections <xref target="sec-trl-endpoint-supporting-diff-queries"/> target="sec-trl-endpoint-supporting-diff-queries" format="counter"/> and <xref target="ssec-trl-diff-query"/>).</t> target="ssec-trl-diff-query" format="counter"/>).</t>
        </li>
        <li>
          <t>A positive integer MAX_DIFF_BATCH, if the AS supports diff queries of the TRL as well as the related "Cursor" extension (see Sections <xref target="sec-trl-endpoint-supporting-cursor"/> target="sec-trl-endpoint-supporting-cursor" format="counter"/> and <xref target="sec-using-cursor"/>).</t> target="sec-using-cursor" format="counter"/>).</t>
        </li>
      </ul>
      <t>Once completed the registration process, process is completed, the AS maintains the registration and related information until a possible deregistration occurs, hence hence, keeping track of active administrators and registered devices. The particular way to achieve this is implementation-specific. Such implementation specific. In any case, such a mechanism to maintain registrations is enforced in any case at the AS, AS in order to ensure that requests sent by clients to the /token endpoint (see <xref section="5.8" sectionFormat="of" target="RFC9200"/>) and by RSs to the /introspect endpoint (see <xref section="5.9" sectionFormat="of" target="RFC9200"/>) are processed as intended.</t>
      <t>When communicating with one another, the registered devices and the AS have to use a secure communication association and be mutually authenticated (see <xref section="5" sectionFormat="of" target="RFC9200"/>).</t> target="RFC9200"/>). </t>

      <t>In the same spirit, it <bcp14>MUST</bcp14> be ensured that communications between the AS and an administrator are <bcp14>MUST</bcp14> be ensured to be mutually authenticated, encrypted encrypted, and integrity protected, protected as well as protected against message replay.</t>
      <t>Before starting its registration process at the AS, an administrator has to establish such a secure communication association with the AS, if they do not share one already. In particular, mutual authentication is <bcp14>REQUIRED</bcp14> during the establishment of the secure association. To this end, the administrator and the AS can rely, e.g., on establishing a TLS or DTLS secure session with mutual authentication (see <xref target="RFC8446"/><xref target="RFC9147"/>, target="RFC8446"/> and <xref target="RFC9147"/>) or an OSCORE Object Security for Constrained RESTful Environments (OSCORE) Security Context <xref target="RFC8613"/> by running the authenticated key exchange protocol EDHOC <xref target="RFC9528"/>.</t>
      <t>When receiving authenticated requests from the administrator for accessing the TRL endpoint, the AS can always check whether the requester is authorized to take such a role, i.e., to access the content of the whole TRL.</t>
      <t>To this end, the AS may rely on a local access control list or similar, which specifies the authentication credentials of trusted, authorized administrators. In particular, the AS verifies the requester to the TRL endpoint as an authorized administrator, administrator only if the access control list includes the same authentication credential used by the requester when establishing the mutually-authenticated mutually authenticated secure communication association with the AS.</t>
      <t>Further details about the registration process at the AS are out of scope for this specification. Note that the registration process is also out of the scope of the ACE framework for Authentication and Authorization (see <xref section="5.5" sectionFormat="of" target="RFC9200"/>).</t>
    </section>
    <section anchor="sec-notification">
      <name>Notification of Revoked Access Tokens</name>
      <t>Once registered at the AS, the administrator or registered device can send a GET request to the TRL endpoint at the AS. The request can express the wish for a full query (see <xref target="ssec-trl-full-query"/>) or a diff query (see <xref target="ssec-trl-diff-query"/>) of the TRL. Also, the request can include the CoAP Observe Option set to 0 (register), (register) in order to start an observation of the TRL endpoint as per <xref section="3.1" sectionFormat="of" target="RFC7641"/>.</t>

      <t>In case the request is successfully processed, the AS replies with a response specifying the CoAP response code 2.05 (Content). In particular, if the AS supports diff queries but not the "Cursor" extension (see Sections <xref target="sec-trl-endpoint-supporting-diff-queries"/> target="sec-trl-endpoint-supporting-diff-queries"  format="counter"/> and <xref target="sec-trl-endpoint-supporting-cursor"/>), target="sec-trl-endpoint-supporting-cursor"  format="counter"/>), then the payload of the response is formatted as defined in Sections <xref target="ssec-trl-full-query"/> target="ssec-trl-full-query" format="counter"/> or in <xref target="ssec-trl-diff-query"/>, target="ssec-trl-diff-query" format="counter"/>, in case the GET request has yielded the execution of a full query or of a diff query of the TRL, respectively. Instead, if the AS supports both diff queries and the related "Cursor" extension, then the payload of the response is formatted as defined in <xref target="sec-using-cursor"/>.</t>
      <t>In case a requester does not receive a response from the TRL endpoint or it receives an error response from the TRL endpoint, the requester does not make any assumption assumptions or draw any conclusion conclusions regarding the revocation or expiration of its pertaining access tokens. The requester <bcp14>MAY</bcp14> try again by sending a new request to the TRL endpoint.</t>
      <t>When the TRL is updated (see <xref target="ssec-trl-update"/>), the AS sends Observe notifications to the observers whose pertaining subset of the TRL has changed. Observe notifications are sent as per <xref section="4.2" sectionFormat="of" target="RFC7641"/>. If supported by the AS, an observer may configure the behavior according to which the AS sends those Observe notifications. To this end, a possible way relies on the conditional control attribute "c.pmax" defined in <xref target="I-D.ietf-core-conditional-attributes"/>, which can be included as a "name=value" query parameter in an Observation Request. This ensures that no more than c.pmax seconds elapse between two consecutive notifications sent to that observer, regardless of whether or not the TRL has changed or not.</t> changed.</t>
      <t>Following a first exchange with the AS, an administrator or a registered device can send additional GET (Observation) requests to the TRL endpoint at any time, analogously to what is defined above. When doing so, the requester towards the TRL endpoint can perform a full query (see <xref target="ssec-trl-full-query"/>) or a diff query (see <xref target="ssec-trl-diff-query"/>) of the TRL. In the latter case, the requester can additionally rely on the "Cursor" extension (see Sections <xref target="sec-trl-endpoint-query-parameters"/> target="sec-trl-endpoint-query-parameters" format="counter"/> and <xref target="sec-using-cursor-diff-query-response"/>).</t> target="sec-using-cursor-diff-query-response" format="counter"/>).</t>
      <t>As specified in <xref target="sec-trl-endpoint-supporting-diff-queries"/>, an AS supporting diff queries maintains an update collection of maximum MAX_N series items for each administrator or registered device, hereafter referred to as requester. a "requester". In particular, if an update collection includes MAX_N series items, adding a further series item to that update collection results in deleting the oldest series item from that update collection.</t>
      <t>From then on, the requester associated with the update collection will not be able to retrieve the deleted series item, item when sending a new diff query request to the TRL endpoint. If that series item reflected the revocation of an access token pertaining to the requester, then the requester will not learn about that when receiving the corresponding diff query response from the AS.</t>
      <t>Sending a diff query request specifically as an Observation request, and thus Request, and, thus, relying on Observe notifications, largely reduces the chances for a requester to miss updates occurred to its associated update collection altogether. collection. In turn, this relies on the requester successfully receiving the Observe notification responses from the TRL (see also <xref target="sec-security-considerations-comm-patterns"/>).</t>
      <t>In order to limit the amount of time during which the requester is unaware of pertaining access tokens that have been revoked but are not expired yet, a requester <bcp14>SHOULD NOT</bcp14> rely solely on diff query requests. In particular, a requester <bcp14>SHOULD</bcp14> also regularly send a full query request to the TRL endpoint according to a related application policy.</t>
      <section anchor="sec-handling-token-hashes">
        <name>Handling of Revoked Access Tokens and Token Hashes</name>
        <t>When receiving a response from the TRL endpoint, a registered device <bcp14>MUST</bcp14> expunge every stored access token associated with a token hash specified in the response. In case the registered device is an RS, it <bcp14>MUST NOT</bcp14> delete the stored token hash after having expunged the associated access token.</t>
        <t>If an RS uses the method defined in this document with the AS that has issued an access token, then the RS <bcp14>MUST NOT</bcp14> accept and store that access token if any of the following holds.</t>
        <ul spacing="normal">
          <li>
            <t>The token hash corresponding to the access token is among the currently stored ones.</t>
          </li>
          <li>
            <t>The access token is a CWT and any of the following holds. holds:  </t>
            <ul spacing="normal">
              <li>
                <t>The access token includes a non-empty "unprotected" field, i.e., the value of the field is not encoded as the empty CBOR map (0xa0). This applies to: to the top-level "unprotected" field of the COSE object used for the CWT; CWT, the "unprotected" field of each element of the "signatures" array; array, and the "unprotected" field of each element of any "recipients" array.</t>
              </li>
              <li>
                <t>The received CBOR data item that embodies the access token does not comply with what is defined in <xref target="sec-issuing-access-tokens-as"/>. This concerns: the concerns:</t><ul>
		<li>the use of exactly two nested CBOR tags, where the outer tag is the CWT CBOR tag and the inner tag is one of the COSE CBOR tags; the tags;</li>
		<li>the tag numbers encoded with the minimum possible length; and the and</li>
		<li>the access token being the innermost tag content of the received CBOR data item.</t> item.</li></ul>
              </li>
              <li>
                <t>In the received CBOR data item that embodies the access token, the inner tag has a tag number that is not consistent with the actual COSE data item to process. For instance, the inner tag number is 16 (COSE_Encrypt0), (COSE_Encrypt0) but the CWT is actually a COSE_Sign data item.</t>
              </li>
            </ul>
          </li>
          <li>
            <t>The access token relies on a JSON object for encoding its claims, but it is not a JWT <xref target="RFC7519"/> and any of the following holds.  </t> holds:</t>
            <ul spacing="normal">
              <li>
                <t>The access token uses the JWS JSON Serialization from <xref target="RFC7515"/>, target="RFC7515"/> and it includes the JWS Unprotected Header.</t>
              </li>
              <li>
                <t>The access token uses the JWE JSON Serialization from <xref target="RFC7516"/>, target="RFC7516"/> and it includes the JWE Shared Unprotected Header and/or includes the "header" member in any of the elements of the "recipients" array.</t>
              </li>
            </ul>
          </li>
        </ul>
        <t>An RS <bcp14>MUST</bcp14> store the token hash th1 corresponding to an access token t1 until both the following conditions hold.</t> hold:</t>
        <ul spacing="normal">
          <li>
            <t>The RS has received and seen t1, irrespective of having accepted and stored it.</t>
          </li>
          <li>
            <t>The RS has gained knowledge that t1 has expired. This can be achieved, e.g., through the following means.  </t> means:</t>
            <ul spacing="normal">
              <li>
                <t>A response from the TRL endpoint indicating that t1 has expired after its earlier revocation, i.e., the token hash th1 has been removed from the TRL. This can be indicated, for instance, in a response from the TRL endpoint following a diff query of the TRL (see <xref target="ssec-trl-diff-query"/>).</t>
              </li>
              <li>
                <t>The value of the 'exp' claim specified in t1 indicates that t1 has expired.</t>
              </li>
              <li>
                <t>The locally determined expiration time for t1 has passed, based on the time at the RS when t1 was first accepted and on the value of its 'exi' claim.</t>
              </li>
              <li>
                <t>The result of token introspection performed on t1 (see <xref section="5.9" sectionFormat="of" target="RFC9200"/>), if supported by both the RS and the AS.</t>
              </li>
            </ul>
          </li>
        </ul>
        <t>The RS <bcp14>MUST NOT</bcp14> delete the stored token hashes whose corresponding access tokens do not fulfill both the two conditions above, unless it becomes necessary due to memory limitations. In such a case, the RS <bcp14>MUST</bcp14> delete the earliest stored token hashes first.</t>
        <t>Retaining the stored token hashes as specified above limits the impact from a (dishonest) client whose pertaining access token: i) specifies token:</t>
	<ol>
	  <li>specifies the 'exi' claim; ii) is claim,</li>
	  <li>is uploaded at the RS for the first time after it has been revoked and later expired; and iii) has expired, and</li>
	<li>has the sequence number encoded in the 'cti' claim (for CWTs) or in the 'jti' claim (for JWTs) greater than the highest sequence number among the expired access tokens specifying the 'exi' claim for the RS (see <xref section="5.10.3" sectionFormat="of" target="RFC9200"/>). That is, the RS would not accept such a revoked and expired access token as long as it stores the corresponding token hash.</t> hash.</li></ol>

<!--[rfced] We have attempted to break up and reorder this long
     sentence.  Please review if the following suggested edit
     correctly captures your intent.

Original:
In order to further limit such a risk, when receiving an access token
that specifies the 'exi' claim and for which a corresponding token
hash is not stored, the RS can introspect the access token (see
Section 5.9 of [RFC9200]), if token introspection is implemented by
both the RS and the AS.

Perhaps:
This risk can be further limited.  Specifically, if token
introspection is implemented by both the RS and the AS, the RS can
introspect the access token (see Section 5.9 of [RFC9200]) when
receiving an access token that specifies the 'exi' claim and for which
a corresponding token hash is not stored.

-->

        <t>In order to further limit such a risk, when receiving an access token that specifies the 'exi' claim and for which a corresponding token hash is not stored, the RS can introspect the access token (see <xref section="5.9" sectionFormat="of" target="RFC9200"/>), if token introspection is implemented by both the RS and the AS.</t>
        <t>When, due to the stored and corresponding token hash th2, an access token t2 that includes the 'exi' claim is expunged or is not accepted upon its upload, the RS retrieves the sequence number sn2 encoded in the 'cti' claim (for CWTs) or in the 'jti' claim (for JWTs) (see <xref section="5.10.3" sectionFormat="of" target="RFC9200"/>). Then, the RS stores sn2 as associated with th2. If expunging or not accepting t2 yields the deletion of th2, then the RS <bcp14>MUST</bcp14> associate sn2 with th2 before continuing with the deletion of th2.</t>
        <t>When deleting any token hash, the RS checks whether the token hash is associated with a sequence number sn_th. In such a case, the RS checks whether sn_th is greater than the highest sequence number sn* among the expired access tokens specifying the 'exi' claim for the RS. If that is the case, sn* <bcp14>MUST</bcp14> take the value of sn_th.</t>
        <t>By virtue of what is defined in <xref section="5.10.3" sectionFormat="of" target="RFC9200"/>, this ensures that, following the deletion of the token hash associated with an access token specifying the 'exi' claim and uploaded for the first time after it has been revoked and later expired, the RS will not accept the access token at that point in time or in the future.</t>
      </section>
    </section>
    <section anchor="trl-registry-parameters">
      <name>ACE Token Revocation List Parameters</name>
      <t>This specification defines a number of parameters that can be transported in the response from the TRL endpoint, when the response payload is a CBOR map. Note that such a response <bcp14>MUST</bcp14> use the Content-Format "application/ace-trl+cbor" defined in <xref target="iana-content-type"/> of this specification.</t>
      <t>The table below summarizes the parameters. For each of them, it specifies the value to use as CBOR key, i.e., as abbreviation in the key of the map pair for the parameter, instead of the parameter's name as a text string.</t>
      <table align="center" anchor="_table-cbor-trl-params">
        <name>CBOR abbreviations Abbreviations for the ACE Token Revocation List parameters</name> Parameters</name>
        <thead>
          <tr>
            <th align="left">Name</th>
            <th align="left">CBOR Key</th>
            <th align="left">CBOR Type</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">full_set</td>
            <td align="left">0</td>
            <td align="left">array</td>
          </tr>
          <tr>
            <td align="left">diff_set</td>
            <td align="left">1</td>
            <td align="left">array</td>
          </tr>
          <tr>
            <td align="left">cursor</td>
            <td align="left">2</td>
            <td align="left">Null or unsigned integer</td>
          </tr>
          <tr>
            <td align="left">more</td>
            <td align="left">3</td>
            <td align="left">True or False</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="error-types">
      <name>ACE Token Revocation List Error Identifiers</name>
      <t>This specification defines a number of values that the AS can use as error identifiers. These are used in error responses with Content-Format "application/concise-problem-details+cbor", as values of the 'error-id' field within the Custom Problem Detail entry 'ace-trl-error' (see <xref target="sec-error-responses"/>).</t>
      <table align="center" anchor="_table-ACE-TRL-Error">
        <name>ACE Token Revocation List Error Identifiers</name>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">0</td>
            <td align="left">Invalid parameter value</td>
          </tr>
          <tr>
            <td align="left">1</td>
            <td align="left">Invalid set of parameters</td>
          </tr>
          <tr>
            <td align="left">2</td>
            <td align="left">Out of bound cursor value</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="sec-security-considerations">
      <name>Security Considerations</name>
      <t>The protocol defined in this document inherits the security considerations from the ACE framework for Authentication and Authorization <xref target="RFC9200"/>, from <xref target="RFC8392"/> as to the usage of CWTs, CWTs from <xref target="RFC7519"/> and <xref target="RFC8725"/> as to target="RFC8392"/>, the usage of JWTs, JWTs from <xref target="RFC7641"/> as to target="RFC7519"/> and <xref target="RFC8725"/>, the usage of CoAP Observe, and Observe from <xref target="RFC6920"/> with regard to computing target="RFC7641"/>, and computation of the token hashes. hashes from <xref target="RFC6920"/>. The following considerations also apply.</t>
      <section anchor="content-retrieval-from-the-trl">
        <name>Content Retrieval from the TRL</name>
        <t>The AS <bcp14>MUST</bcp14> ensure that each registered device can access and retrieve only its pertaining subset of the TRL. To this end, the AS can always perform the required filtering based on the authenticated identity of the registered device, i.e., a (non-public) identifier that the AS can securely relate to the registered device and the secure association that they use to communicate.</t>
        <t>The AS <bcp14>MUST</bcp14> ensure that, other than registered devices accessing their own pertaining subset of the TRL, only authorized and authenticated administrators can access the content of the whole TRL (see <xref target="sec-registration"/>).</t>
        <t>Note that the TRL endpoint supports only the GET method (see <xref target="sec-trl-endpoint"/>). Therefore, as detailed in Sections <xref target="ssec-trl-full-query"/> target="ssec-trl-full-query" format="counter"/> and <xref target="ssec-trl-diff-query"/>, accesses target="ssec-trl-diff-query" format="counter"/>, access to the TRL endpoint are is performed only by means of protected and authenticated GET requests, which which, by definition definition, are safe in the REST sense and do not alter the content of the TRL. That is, registered devices and administrators can perform exclusively read-only operations when accessing the TRL endpoint.</t>
        <t>In fact, the two circumstances described in <xref target="ssec-trl-update"/>, the content of the TRL can be updated only internally by the AS, in the two circumstances described in <xref target="ssec-trl-update"/>. AS.  Therefore, an adversary that is not in control of the AS cannot manipulate the content of the TRL, e.g., by removing a token hash and thereby fraudulently allowing a client to access protected resources in spite of a revoked access token, token or by adding a token hash and thereby fraudulently stopping a client from accessing protected resources in spite of an access token being still valid.</t>
      </section>
      <section anchor="size-of-the-trl">
        <name>Size of the TRL</name>
        <t>If many non-expired access tokens associated with a registered device are revoked, the pertaining subset of the TRL could grow to a size bigger than what the registered device is prepared to handle upon reception of a response from the TRL endpoint, especially if relying on a full query of the TRL (see <xref target="ssec-trl-full-query"/>).</t>
        <t>This could be exploited by attackers to negatively affect the behavior of a registered device. Therefore, in order to help reduce the size of the TRL, the AS <bcp14>SHOULD</bcp14> refrain from issuing access tokens with an excessively long expiration time.</t>
      </section>
      <section anchor="sec-security-considerations-comm-patterns">
        <name>Communication Patterns</name>
        <t>The communication about revoked access tokens presented in this specification is expected to especially rely on CoAP Observe notifications sent from the AS to a requester (i.e., an administrator or a registered device). The suppression of those notifications by an external attacker that has access to the network would prevent requesters from ever knowing that their pertaining access tokens have been revoked.</t>
        <t>In order to avoid this, a requester <bcp14>SHOULD NOT</bcp14> rely solely on the CoAP Observe notifications. In particular, a requester <bcp14>SHOULD</bcp14> also regularly poll the AS for the most current information about revoked access tokens, tokens by sending GET requests to the TRL endpoint. Specific strategies and schedules for polling the AS are to be defined by a related application policy, policy and by also taking into account the expected operational and availability patterns adopted by the requester (e.g., in the interest of energy saving and other optimizations).</t>
      </section>
      <section anchor="request-of-new-access-tokens">
        <name>Request of New Access Tokens</name>
        <t>If a client stores an access token that it still believes to be valid, and it accordingly attempts to access a protected resource at the RS, the client may receive an unprotected 4.01 (Unauthorized) response from the RS.</t>
        <t>This can be due to a number of causes. For example, the causes, for example:</t>
	<ul>
	  <li>the access token has been revoked, and the RS has become aware of it it, and the RS has expunged the access token, but the client is not aware of it (yet). As another example, the this (yet).</li>
	  <li>the access token is still valid, but an on-path active adversary might have injected a forged 4.01 (Unauthorized) response, response or the RS might have deleted the access token from its local storage due to its dedicated storage space being all consumed.</t> consumed.</li></ul>
        <t>In either case, if the client believes that the access token is still valid, it <bcp14>SHOULD NOT</bcp14> immediately ask for a new access token to the authorization server upon receiving a 4.01 (Unauthorized) response from the RS. Instead, the client <bcp14>SHOULD</bcp14> send a request to the TRL endpoint at the AS. If the client gains knowledge that the access token is not valid anymore, the client expunges the access token and can ask for a new one. Otherwise, the client can try again to upload the same access token to the RS, RS or instead to request a new one.</t>
      </section>
      <section anchor="vulnerable-time-window-at-the-rs">
        <name>Vulnerable Time Window at the RS</name>
        <t>A client may attempt to access a protected resource at an RS after the access token allowing such an access has been revoked, revoked but before the RS is aware of the revocation.</t>
        <t>In such a case, if the RS is still storing the access token, the client will be able to access the protected resource, resource even though it should not. Such an access is a security violation, even if the client is not attempting to be malicious.</t>
        <t>In order to minimize such a risk, if an RS relies solely on polling through individual requests to the TRL endpoint to learn of revoked access tokens, the RS <bcp14>SHOULD</bcp14> implement an adequate trade-off between the polling frequency and the maximum length of the vulnerable time window.</t>
      </section>
      <section anchor="sec-seccons-token-manipulation">
        <name>Preventing Unnoticed Manipulation of Access Tokens</name>
        <t>As defined in <xref target="sec-issuing-access-tokens-as"/>, issued access tokens <bcp14>MUST NOT</bcp14> rely on unprotected headers to specify information as header parameters. Also, when issued access tokens are CWTs, they <bcp14>MUST</bcp14> be tagged by using the COSE CBOR tag corresponding to the used COSE object, object.  Further, the result <bcp14>MUST</bcp14> be in turn tagged by using the CWT CBOR tag, and tag; no further tagging is performed.</t>
        <t>This ensures that the RS always computes the correct token hash corresponding to an access token, i.e., the same token hash computed by the AS and C for that access token.</t>
        <t>By construction, the rules defined in <xref target="sec-issuing-access-tokens-as"/> prevent an active adversary from successfully performing an attack against the RS, which would otherwise be possible in case the access token is uploaded to the RS over an unprotected communication channel.</t>
        <t>In such an attack, the adversary intercepts the access token when this is sent en route to the RS. Then, the adversary manipulates the access token in a way which that is going to be unnoticed by the RS, RS but without preventing the successful, successful cryptographic validation of the access token at the RS. To this end, the adversary has two possible options:</t>
        <ul spacing="normal">
          <li>
            <t>Adding and/or removing fields within the unprotected header(s) of the access token, as long as those fields do not play a role in the cryptographic validation of the access token.</t>
          </li>
          <li>
            <t>Specifically when the access token is a CWT, adding/removing adding, removing, or manipulating possible CBOR tag(s) tags enclosing the access token.</t>
          </li>
        </ul>
        <t>After that, the adversary sends the manipulated access token to the RS.</t>
        <t>After having successfully validated the manipulated access token, the RS computes a corresponding token hash different from the one computed and stored by C and the AS. Finally, the RS stores the manipulated access token and the corresponding wrong token hash.</t>
        <t>Later on, if the access token is revoked and the AS provides the RS with the corresponding correct token hash, the RS does not recognize the received token hash among the stored ones, and therefore ones; therefore, it does not delete the revoked access token.</t>
      </section>
      <section anchor="sec-seccons-two-hashes-jwt">
        <name>Two Token Hashes at the RS using Using JWTs</name>
        <t><xref target="sec-token-hash-input-rs-jwt"/> defines states that an RS using JWTs as access tokens has to compute and store two token hashes associated with the same access token. This is because, when using JWTs, the RS does not know for sure if the AS provided the access token to the client by means of an AS-to-Client response encoded in CBOR or in JSON.</t>
        <t>Taking advantage of that, a dishonest client can attempt to perform an attack against the RS. That is, the client can first receive the JWT in an AS-to-Client response encoded in CBOR (JSON). Then, the client can upload the JWT to the RS in a way that makes the RS believe that the client instead received the JWT in an AS-to-Client response encoded in JSON (CBOR).</t>
        <t>Consequently, the RS considers a HASH_INPUT different from the one considered by the AS and the client (see <xref target="sec-token-hash-input-c-as"/>). Hence, the RS computes a token hash h' different from the token hash h computed by the AS and the client. It follows that, if the AS revokes the access token and advertises the right token hash h, then the RS will not learn about the access token revocation and thus revocation; thus, it will not delete the access token.</t>
        <t>Fundamentally, this would happen because the HASH_INPUT used to compute the token hash of a JWT depends on whether the AS-to-Client response is encoded in CBOR or in JSON. This makes the RS vulnerable to the attack described above, above when JWTs are used as access tokens. Instead, However, this is not a problem if the access token is a CWT, CWT since the HASH_INPUT used to compute the token hash of a CWT does not depend on whether the AS-to-Client response is encoded in CBOR or in JSON.</t>
        <t>While this asymmetry cannot be avoided altogether, the method defined for the AS and the client in <xref target="sec-token-hash-input-c-as"/> deliberately penalizes the case where the RS uses JWTs as access tokens. In such a case, the RS effectively neutralizes the attack described above, above by computing and storing two token hashes associated with the same access token (see <xref target="sec-token-hash-input-rs-jwt"/>).</t>
        <t>Conversely, this design deliberately favors the case where the RS uses CWTs as access tokens, which is a preferable option for resource-constrained RSs as well as the default case in the ACE framework for Authentication and Authorization (see <xref section="3" sectionFormat="of" target="RFC9200"/>). That is, if an RS uses CWTs as access tokens, then the RS is not exposed to the attack described above, and thus above; thus, it safely computes and stores only one token hash per access token (see <xref target="sec-token-hash-input-rs-cwt"/>).</t>
      </section>
      <section anchor="additional-security-measures">
        <name>Additional Security Measures</name>
        <t>By accessing the TRL at the AS, registered devices and administrators are able to learn that their pertaining access tokens have been revoked. However, they cannot learn the reason why that happened, why, including when that reason is the compromise, misbehavior, or decommissioning of a registered device.</t>
        <t>In fact, even the AS might not know that a registered device to which a revoked access token pertains has been specifically compromised, misbehaving, or decommissioned. At the same time, it might not be acceptable to only revoke the access tokens pertaining to such a registered device.</t>
        <t>Therefore, in order to preserve the security of the system and application, the entity that authoritatively declares a registered device to be compromised, misbehaving, or decommissioned should also promptly trigger the execution of additional revocation processes as deemed appropriate. These include, for instance:</t>
        <ul spacing="normal">
          <li>
            <t>The de-registration of the registered device from the AS, AS so that the AS does not issue further access tokens pertaining to that device.</t>
          </li>
          <li>
            <t>If applicable, the revocation of the public authentication credential associated with the registered device (e.g., its public key certificate).</t>
          </li>
        </ul>
        <t>The methods by which these processes are triggered and carried out are out of the scope of this document.</t>
      </section>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This document has the following
      <t>The IANA actions for IANA.</t>
      <t>Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.</t> document are described in the following subsections.</t>
      <section anchor="iana-media-type">
        <name>Media Type Registrations</name>
        <t>IANA is asked to register has registered the media type "application/ace-trl+cbor" for messages of the protocol defined in this document encoded in CBOR. This registration follows the procedures specified in <xref target="RFC6838"/>.</t>
        <t>Type name: application</t>
        <t>Subtype name: ace-trl+cbor</t>
        <t>Required parameters: N/A</t>
        <t>Optional parameters: N/A</t>
        <t>Encoding considerations: Must
	<dl newline="false">
          <dt>Type name:</dt><dd>application</dd>
          <dt>Subtype name:</dt><dd>ace-trl+cbor</dd>
          <dt>Required parameters:</dt><dd>N/A</dd>
          <dt>Optional parameters:</dt><dd>N/A</dd>
          <dt>Encoding considerations:</dt><dd>Must be encoded as a CBOR map
          containing the protocol parameters defined in [RFC-XXXX].</t>
        <t>Security considerations: See RFC 9770.</dd>
          <dt>Security considerations:</dt><dd>See <xref target="sec-security-considerations"/> of this document.</t>
        <t>Interoperability considerations: N/A</t>
        <t>Published specification: [RFC-XXXX]</t>
        <t>Applications document.</dd>
          <dt>Interoperability considerations:</dt><dd>N/A</dd>
          <dt>Published specification:</dt><dd>RFC 9770</dd>
          <dt>Applications that use this media type: The type:</dt><dd>The type is used
          by authorization servers, clients, and resource servers that support
          the notification of revoked access tokens, tokens according to a Token
          Revocation List maintained by the authorization server as specified
          in [RFC-XXXX].</t>
        <t>Fragment RFC 9770.</dd>
          <dt>Fragment identifier considerations: N/A</t>
        <t>Additional information: N/A</t>
        <t>Person considerations:</dt><dd>N/A</dd>
          <dt>Additional information:</dt><dd>N/A</dd>
          <dt>Person &amp; email address to contact for further information: ACE
          information:</dt><dd>ACE WG mailing list (ace@ietf.org) or IETF
          Applications and Real-Time Area (art@ietf.org)</t>
        <t>Intended usage: COMMON</t>
        <t>Restrictions (art@ietf.org)</dd>
          <dt>Intended usage:</dt><dd>COMMON</dd>
          <dt>Restrictions on usage: None</t>
        <t>Author/Change controller: IETF</t>
        <t>Provisional registration: No</t> usage:</dt><dd>None</dd>
          <dt>Author/Change controller:</dt><dd>IETF</dd>
	</dl>
      </section>
      <section anchor="iana-content-type">
        <name>CoAP Content-Formats Registry</name>
        <t>IANA is asked to add has added the following entry to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.</t>
        <t>Content Type: application/ace-trl+cbor</t>
        <t>Content Coding: -</t>
        <t>ID: TBD</t>
        <t>Reference: [RFC-XXXX]</t>
	<dl newline="false" spacing="compact">
          <dt>Content Type:</dt><dd>application/ace-trl+cbor</dd>
          <dt>Content Coding:</dt><dd>-</dd>
          <dt>ID:</dt><dd>262</dd>
          <dt>Reference:</dt><dd>RFC 9770</dd>
	</dl>
      </section>

      <section anchor="iana-custom-problem-details">
        <name>Custom Problem Detail Keys Registry</name>
        <t>IANA is asked to register has registered the following entry in the "Custom Problem Detail Keys" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.</t>
        <ul spacing="normal">
          <li>
            <t>Key Value: TBD</t>
          </li>
          <li>
            <t>Name: ace-trl-error</t>
          </li>
          <li>
            <t>Brief Description: Carry [RFC-XXXX]
	<dl newline="false" spacing="compact">
          <dt>Key Value:</dt><dd>1</dd>
          <dt>Name:</dt><dd>ace-trl-error</dd>
          <dt>Brief Description:</dt><dd>Carry RFC 9770 problem details in a Concise Problem Details data item.</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
          <li>
            <t>Reference: <xref item.</dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
          <dt>Reference:</dt><dd><xref target="sec-error-responses"/> of [RFC-XXXX]</t>
          </li>
        </ul> RFC 9770</dd>
        </dl>
      </section>
      <section anchor="iana-token-revocation-list">
        <name>ACE Token Revocation List Parameters Registry</name>
        <t>IANA is asked to establish has established the "ACE Token Revocation List Parameters" IANA  registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t>
        <t>As registration policy,
        <t>One of the registry uses either following registration policies is used: "Standards Action with Expert Review", or "Specification Required" per <xref section="4.6" sectionFormat="of" target="RFC8126"/>, or "Expert Review" per <xref section="4.5" sectionFormat="of" target="RFC8126"/>. Expert Review guidelines are provided in <xref target="review"/>.</t>
        <t>All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per <xref section="4.9" sectionFormat="of" target="RFC8126"/>, target="RFC8126"/> with Expert Review additionally required per <xref section="4.5" sectionFormat="of" target="RFC8126"/>. The procedure for early IANA allocation of Standards Track code points defined in <xref target="RFC7120"/> also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in <xref section="3.1" sectionFormat="of" target="RFC7120"/>.</t>
        <t>The columns of this registry are:</t> are as follows:</t>
        <ul spacing="normal">
          <li>
            <t>Name:
          <li>Name: This field contains a descriptive name that
          enables easier reference to the item. The name <bcp14>MUST</bcp14>
          be unique unique, and it is not used in the encoding.</t>
          </li>
          <li>
            <t>CBOR encoding.</li>

          <li>CBOR Key: This field contains the value used as CBOR map
          key of the item. The value <bcp14>MUST</bcp14> be unique. The value
          is an unsigned integer or a negative integer. Different ranges of
          values use different registration policies <xref
          target="RFC8126"/>. Integer values from -256 to 255 are designated
          as "Standards Action With Expert Review". Integer values from -65536
          to -257 and from 256 to 65535 are designated as "Specification
          Required". Integer values greater than 65535 are designated as
          "Expert Review". Integer values less than -65536 are marked as
          "Private Use".</t>
          </li>
          <li>
            <t>CBOR Use".</li>

          <li>CBOR Type: This field contains the allowable CBOR data
          types for values of this item, item or a pointer to the registry that
          defines its type, when that depends on another item.</t>
          </li>
          <li>
            <t>Reference: item.</li>

          <li>Reference: This field contains a pointer to the public
          specification for the item.</t>
          </li> item.</li>
        </ul>
        <t>This registry has been initially populated by the values in <xref target="trl-registry-parameters"/>. The "Reference" column for all of these entries refers to this document.</t>
      </section>
      <section anchor="iana-token-revocation-list-errors">
        <name>ACE Token Revocation List Errors</name>
        <t>IANA is asked to establish has established the "ACE Token Revocation List Errors" IANA  registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t>
        <t>As registration policy,
        <t>One of the registry uses either following registration policies is used: "Standards Action with Expert Review", or "Specification Required" per <xref section="4.6" sectionFormat="of" target="RFC8126"/>, or "Expert Review" per <xref section="4.5" sectionFormat="of" target="RFC8126"/>. Expert Review guidelines are provided in <xref target="review"/>.</t>
        <t>All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per <xref section="4.9" sectionFormat="of" target="RFC8126"/>, target="RFC8126"/> with Expert Review additionally required per <xref section="4.5" sectionFormat="of" target="RFC8126"/>. The procedure for early IANA allocation of Standards Track code points defined in <xref target="RFC7120"/> also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in <xref section="3.1" sectionFormat="of" target="RFC7120"/>.</t>
        <t>The columns of this registry are:</t> are as follows:</t>
        <ul spacing="normal">
          <li>
            <t>Value: The field contains the value to be used to identify the error. The value <bcp14>MUST</bcp14> be unique. The value is an unsigned integer or a negative integer. Different ranges of values use different registration policies <xref target="RFC8126"/>. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".</t>
          </li>
          <li>
            <t>Description: This field contains a brief description of the error.</t>
          </li>
          <li>
            <t>Reference: This field contains a pointer to the public specification defining the error, if one exists.</t>
          </li>
        </ul>
        <t>This registry has been initially populated by the values in <xref target="error-types"/>. The "Reference" column for all of these entries refers to this document.</t>
      </section>
      <section anchor="review">
        <name>Expert Review Instructions</name>
        <t>The IANA registries established in by this document are defined as use "Standards Action with Expert Review", "Specification Required", or "Expert Review", Review" registration procedures depending on the range of values for which an assignment is requested. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason reason, so they should be given substantial latitude.</t>
        <t>Expert reviewers should take into consideration the following points:</t>
        <ul spacing="normal">
          <li>
            <t>Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as private use Private Use are intended for testing purposes and closed environments. Code points in other ranges should not be assigned for testing.</t>
          </li>
          <li>
            <t>Specifications are required for the "Standards Action With Expert Review" range of point assignment. Specifications should exist for "Specification Required" ranges, but early assignment before a specification is available is considered to be permissible. For the "Expert Review" range of point assignment, specifications are recommended, recommended and are needed if they are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.</t>
          </li>
          <li>
            <t>Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.</t>
          </li>
        </ul>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.bormann-t2trg-stp" to="STP"/>
    <displayreference target="I-D.ietf-core-conditional-attributes" to="CoRE-ATTRIBUTES"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6920.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7120.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7641.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7516.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8392.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8725.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9052.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9200.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9528.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9202.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9203.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9290.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9431.xml"/>

        <reference anchor="RFC3629"> anchor="IANA.Hash.Algorithms" target="https://www.iana.org/assignments/named-information">
          <front>
            <title>UTF-8, a transformation format of ISO 10646</title>
            <author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
            <date month="November" year="2003"/>
            <abstract>
              <t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="63"/>
          <seriesInfo name="RFC" value="3629"/>
          <seriesInfo name="DOI" value="10.17487/RFC3629"/>
        </reference>
        <reference anchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <date month="October" year="2006"/>
            <abstract>
              <t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>
        <reference anchor="RFC6347">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
            <date month="January" year="2012"/>
            <abstract>
              <t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6347"/>
          <seriesInfo name="DOI" value="10.17487/RFC6347"/>
        </reference>
        <reference anchor="RFC6749">
          <front>
            <title>The OAuth 2.0 Authorization Framework</title>
            <author fullname="D. Hardt" initials="D." role="editor" surname="Hardt"/>
            <date month="October" year="2012"/>
            <abstract>
              <t>The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6749"/>
          <seriesInfo name="DOI" value="10.17487/RFC6749"/>
        </reference>
        <reference anchor="RFC6838">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="January" year="2013"/>
            <abstract>
              <t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t>
            </abstract>
            <title>Named Information Hash Algorithm Registry</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
          <seriesInfo name="BCP" value="13"/>
          <seriesInfo name="RFC" value="6838"/>
          <seriesInfo name="DOI" value="10.17487/RFC6838"/>
        </reference>
        <reference anchor="RFC6920">
          <front>
            <title>Naming Things with Hashes</title>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="D. Kutscher" initials="D." surname="Kutscher"/>
            <author fullname="C. Dannewitz" initials="C." surname="Dannewitz"/>
            <author fullname="B. Ohlman" initials="B." surname="Ohlman"/>
            <author fullname="A. Keranen" initials="A." surname="Keranen"/>
            <author fullname="P. Hallam-Baker" initials="P." surname="Hallam-Baker"/>
            <date month="April" year="2013"/>
            <abstract>
              <t>This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names.

<!-- [rfced] [SHA-256] The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6920"/>
          <seriesInfo name="DOI" value="10.17487/RFC6920"/>
        </reference>
        <reference anchor="RFC7120">
          <front>
            <title>Early IANA Allocation of Standards Track Code Points</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <date month="January" year="2014"/>
            <abstract>
              <t>This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="100"/>
          <seriesInfo name="RFC" value="7120"/>
          <seriesInfo name="DOI" value="10.17487/RFC7120"/>
        </reference>
        <reference anchor="RFC7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
            <author fullname="K. Hartke" initials="K." surname="Hartke"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2014"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
              <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, NIST FIPS 180-3 was very low overhead, and simplicity for constrained environments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7252"/>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
        </reference>
        <reference anchor="RFC7641">
          <front>
            <title>Observing Resources in the Constrained Application Protocol (CoAP)</title>
            <author fullname="K. Hartke" initials="K." surname="Hartke"/>
            <date month="September" year="2015"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7641"/>
          <seriesInfo name="DOI" value="10.17487/RFC7641"/>
        </reference>
        <reference anchor="RFC8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
            <date month="December" year="2017"/>
            <abstract>
              <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It
     outdated. FIPS 180-3 was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
        <reference anchor="RFC7515">
          <front>
            <title>JSON Web Signature (JWS)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <date month="May" year="2015"/>
            <abstract>
              <t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7515"/>
          <seriesInfo name="DOI" value="10.17487/RFC7515"/>
        </reference>
        <reference anchor="RFC7516">
          <front>
            <title>JSON Web Encryption (JWE)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Hildebrand" initials="J." surname="Hildebrand"/>
            <date month="May" year="2015"/>
            <abstract>
              <t>JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined superseded by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described FIPS 180-4 in the separate JSON Web Signature (JWS) specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7516"/>
          <seriesInfo name="DOI" value="10.17487/RFC7516"/>
        </reference>
        <reference anchor="RFC7519">
          <front>
            <title>JSON Web Token (JWT)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <date month="May" year="2015"/>
            <abstract>
              <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. 2012. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7519"/>
          <seriesInfo name="DOI" value="10.17487/RFC7519"/>
        </reference>
        <reference anchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8392">
          <front>
            <title>CBOR Web Token (CWT)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="May" year="2018"/>
            <abstract>
              <t>CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8392"/>
          <seriesInfo name="DOI" value="10.17487/RFC8392"/>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="C. Vigano" initials="C." surname="Vigano"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2019"/>
            <abstract>
              <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <reference anchor="RFC8613">
          <front>
            <title>Object Security for Constrained RESTful Environments (OSCORE)</title>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="J. Mattsson" initials="J." surname="Mattsson"/>
            <author fullname="F. Palombini" initials="F." surname="Palombini"/>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <date month="July" year="2019"/>
            <abstract>
              <t>This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</t>
              <t>Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8613"/>
          <seriesInfo name="DOI" value="10.17487/RFC8613"/>
        </reference>
        <reference anchor="RFC8725">
          <front>
            <title>JSON Web Token Best Current Practices</title>
            <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
            <author fullname="D. Hardt" initials="D." surname="Hardt"/>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="February" year="2020"/>
            <abstract>
              <t>JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="225"/>
          <seriesInfo name="RFC" value="8725"/>
          <seriesInfo name="DOI" value="10.17487/RFC8725"/>
        </reference>
        <reference anchor="RFC8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="December" year="2020"/>
            <abstract>
              <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new
     latest version of the format.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference>
        <reference anchor="RFC9052">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</t>
              <t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="96"/>
          <seriesInfo name="RFC" value="9052"/>
          <seriesInfo name="DOI" value="10.17487/RFC9052"/>
        </reference>
        <reference anchor="RFC9147">
          <front>
            <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
            <date month="April" year="2022"/>
            <abstract>
              <t>This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t>
              <t>This document obsoletes RFC 6347.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9147"/>
          <seriesInfo name="DOI" value="10.17487/RFC9147"/>
        </reference>
        <reference anchor="RFC9200">
          <front>
            <title>Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)</title>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This specification defines a framework for authentication and authorization standard was released in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined August 2015. We
     have updated to better serve the IoT use cases.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9200"/>
          <seriesInfo name="DOI" value="10.17487/RFC9200"/>
        </reference> most recent version. Please let us know any
     objections-->

        <reference anchor="RFC9528"> anchor="SHA-256" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">
          <front>
            <title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Mattsson"/>
            <author fullname="F. Palombini" initials="F." surname="Palombini"/>
            <title>Secure Hash Standard</title>
            <author>
              <organization>NIST</organization>
            </author>
            <date month="March" year="2024"/>
            <abstract>
              <t>This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low.</t>
            </abstract> year="2015" month="August"/>
          </front>
          <seriesInfo name="RFC" value="9528"/> name="NIST FIPS PUB" value="180-4"/>
	  <seriesInfo name="DOI" value="10.17487/RFC9528"/> value="10.6028/NIST.FIPS.180-4"/>
	</reference>
        <reference anchor="RFC9202">
          <front>
            <title>Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)</title>
            <author fullname="S. Gerdes" initials="S." surname="Gerdes"/>
            <author fullname="O. Bergmann" initials="O." surname="Bergmann"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This specification defines a profile of the Authentication and Authorization

<!--  OLD XML for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS withdrawn version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9202"/>
          <seriesInfo name="DOI" value="10.17487/RFC9202"/>
        </reference>
        <reference anchor="RFC9203">
          <front>
            <title>The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework</title>
            <author fullname="F. Palombini" initials="F." surname="Palombini"/>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="M. Gunnarsson" initials="M." surname="Gunnarsson"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9203"/>
          <seriesInfo name="DOI" value="10.17487/RFC9203"/>
        </reference>
        <reference anchor="RFC9290">
          <front>
            <title>Concise Problem Details for Constrained Application Protocol (CoAP) APIs</title>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="October" year="2022"/>
            <abstract>
              <t>This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9290"/>
          <seriesInfo name="DOI" value="10.17487/RFC9290"/>
        </reference>
        <reference anchor="RFC9431">
          <front>
            <title>Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework</title>
            <author fullname="C. Sengul" initials="C." surname="Sengul"/>
            <author fullname="A. Kirby" initials="A." surname="Kirby"/>
            <date month="July" year="2023"/>
            <abstract>
              <t>This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework to enable authorization in a publish-subscribe messaging system based on Message Queuing Telemetry Transport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9431"/>
          <seriesInfo name="DOI" value="10.17487/RFC9431"/>
        </reference>
        <reference anchor="Named.Information.Hash.Algorithm" target="https://www.iana.org/assignments/named-information/named-information.xhtml">
          <front>
            <title>Named Information Hash Algorithm</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference> [SHA-256]
        <reference anchor="SHA-256" target="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf">
          <front>
            <title>Secure Hash Standard</title>
            <author>
              <organization>NIST</organization>
            </author>
            <date year="2008" month="October"/>
          </front>
          <seriesInfo name="FIPS 180-3" value=""/>
        </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 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 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 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 in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage 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>
-->
        <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>
        <name>Informative References</name>
        <reference anchor="RFC7009">
          <front>
            <title>OAuth 2.0 Token Revocation</title>
            <author fullname="T. Lodderstedt" initials="T." role="editor" surname="Lodderstedt"/>
            <author fullname="S. Dronia" initials="S." surname="Dronia"/>
            <author fullname="M. Scurtescu" initials="M." surname="Scurtescu"/>
            <date month="August" year="2013"/>
            <abstract>
              <t>This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7009"/>
          <seriesInfo name="DOI" value="10.17487/RFC7009"/>
        </reference>
        <reference anchor="I-D.ietf-core-conditional-attributes">
          <front>
            <title>Conditional Attributes for Constrained RESTful Environments</title>
            <author fullname="Michael Koster" initials="M." surname="Koster">
              <organization>Dogtiger Labs</organization>
            </author>
            <author fullname="Alan Soloway" initials="A." surname="Soloway">
              <organization>Qualcomm Technologies</organization>
            </author>
            <author fullname="Bill Silverajan" initials="B." surname="Silverajan">
              <organization>Tampere University</organization>
            </author>
            <date day="8" month="July" year="2024"/>
            <abstract>
              <t>   This specification defines Conditional Notification and Control
   Attributes that work with CoAP Observe (RFC7641).

Editor note

   The git repository for the draft is found at https://github.com/core-
   wg/conditional-attributes/

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-conditional-attributes-07"/>
        </reference>
        <reference anchor="I-D.bormann-t2trg-stp">
          <front>
            <title>The Series Transfer Pattern (STP)</title>
            <author fullname="Carsten Bormann" initials="C." surname="Bormann">
              <organization>Universität Bremen TZI</organization>
            </author>
            <author fullname="Klaus Hartke" initials="K." surname="Hartke">
              <organization>Ericsson</organization>
            </author>
            <date day="7" month="April" year="2020"/>
            <abstract>
              <t>   Many applications make use of Series of data items, i.e., an array
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7009.xml"/>
<!-- [I-D.ietf-core-conditional-attributes] IESG State: I-D Exists as of
   data items where new items can be added over time.  Where such Series
   are to be made available using REST protocols such 12/12/24 -->

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-conditional-attributes.xml"/>
<!-- [I-D.bormann-t2trg-stp] IESG State: Expired as CoAP or HTTP,
   the Series has to be mapped into a structure of one or more resources
   and a protocol for a client to obtain the Series and to learn about
   new items.

   Various protocols have been standardized that make Series-shaped data
   available, with rather different properties and objectives.  The
   present document is an attempt to extract a common underlying pattern
   and to define media types and an access scheme that can be used right
   away for further protocols that provide Series-shaped data.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-bormann-t2trg-stp-03"/>
        </reference> 12/12/24 -->

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.bormann-t2trg-stp.xml"/>
      </references>
    </references>
    <section anchor="sec-series-pattern">
      <name>On using Using the Series Transfer Pattern</name>
      <t>Performing a diff query of the TRL as specified in <xref target="ssec-trl-diff-query"/> is is, in fact fact, a usage example of the Series Transfer Pattern defined in <xref target="I-D.bormann-t2trg-stp"/>.</t>
      <t>That is, a diff query enables the transfer of a series of diff entries, entries with the AS specifying U &lt;= MAX_N diff entries as related to the U most recent TRL updates pertaining to a requester, i.e., a registered device or an administrator.</t>
      <t>When responding to a diff query request from a requester (see <xref target="ssec-trl-diff-query"/>), 'diff_set' is a subset of the update collection associated with the requester, requester where each 'diff_entry' record is a series item from that update collection. Note that 'diff_set' specifies the whole current update collection when the value of U is equal to SIZE, i.e., the current number of series items in the update collection.</t>
      <t>The value N of the 'diff' query parameter in the GET request allows the requester and the AS to trade the amount of provided information with the latency of the information transfer.</t>
      <t>Since the update collection associated with each requester includes up to MAX_N series items, the AS deletes the oldest series item when a new one is generated and added to the end of the update collection, due to a new TRL update pertaining to that requester (see <xref target="sec-trl-endpoint-supporting-diff-queries"/>). This addresses the question "When can the server decide to no longer retain older items?" raised in <xref section="3.2" sectionFormat="of" target="I-D.bormann-t2trg-stp"/>.</t>

      <t>Furthermore, performing a diff query of the TRL together with the "Cursor" extension extension, as specified in <xref target="sec-using-cursor"/> target="sec-using-cursor"/>, in fact fact, relies on the "Cursor" pattern of the Series Transfer Pattern STP (see <xref section="3.3" sectionFormat="of" target="I-D.bormann-t2trg-stp"/>).</t>
    </section>
    <section anchor="sec-trl-parameteters">
      <name>Local Supportive Parameters of the TRL Endpoint</name>
      <t><xref target="_table-TRL-endpoint-parameters"/> provides an aggregated overview of the local supportive parameters that the AS internally uses at its TRL endpoint, endpoint when supporting diff queries (see <xref target="sec-trl-endpoint"/>) and the "Cursor" extension (see <xref target="sec-trl-endpoint-supporting-cursor"/>).</t>
      <t>Except for MAX_N defined in <xref target="sec-trl-endpoint-supporting-diff-queries"/>, all the other parameters are defined in <xref target="sec-trl-endpoint-supporting-cursor"/> and are used only if the AS supports the "Cursor" extension.</t>
      <t>For each parameter, the columns of the table specify the following information. Both a registered device and an administrator are referred to as "requester".</t>
      <ul
      <dl spacing="normal">
        <li>
          <t>Name:
        <dt>Name:</dt><dd>The parameter name. A name with letters in uppercase denotes a parameter whose value does not change after its initialization.</t>
        </li>
        <li>
          <t>Single instance: "Y", initialization.
        </dd>

          <dt>Single instance:</dt><dd>"Y" if there is a single parameter instance associated with the TRL; TRL or "N", "N" if there is one parameter instance per update collection (i.e., per requester).</t>
        </li>
        <li>
          <t>Description: requester).</dd>

          <dt>Description:</dt><dd>A short parameter description.</t>
        </li>
        <li>
          <t>Values: description of the parameter.</dd>

          <dt>Values:</dt><dd>The unsigned integer values that the parameter can assume, where LB and UB denote the inclusive lower bound and upper bound, respectively, and "^" is the exponentiation operator.</t>
        </li>
      </ul> operator.</dd>
        </dl>

<!--[rfced] We noticed that Table 3 contains the only use of 'index' parameter.  Please ensure parameter (and not value or unsigned integer) was intended.

Original:
Max value of each instance of the 'index' parameter

-->

      <table align="center" anchor="_table-TRL-endpoint-parameters">
        <name>Local Supportive Parameters of the TRL Endpoint</name>
        <thead>
          <tr>
            <th align="left">Name</th>
            <th align="left">Single  instance</th>
            <th align="left">Description</th>
            <th align="left">Values</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">MAX_N</td>
            <td align="left">Y</td>
            <td align="left">Max number of series items in the update collection of each requester</td>
            <td align="left">LB = 1 <br/><br/> If supporting <br/> "Cursor", then <br/> UB = MAX_INDEX+1</td>
          </tr>
          <tr>
            <td align="left">MAX_DIFF_BATCH</td>
            <td align="left">N</td>
            <td align="left">Max number of diff entries included in a diff query response when using "Cursor"</td>
            <td align="left">LB = 1 <br/><br/> UB = MAX_N</td>
          </tr>
          <tr>
            <td align="left">MAX_INDEX</td>
            <td align="left">Y</td>
            <td align="left">Max value of each instance of the 'index' parameter</td>
            <td align="left">LB = MAX_N-1 <br/><br/> UB = (2^64)-1</td>
          </tr>
          <tr>
            <td align="left">index</td>
            <td align="left">N</td>
            <td align="left">Value associated with a series item of an update collection</td>
            <td align="left">LB = 0 <br/><br/> UB = MAX_INDEX</td>
          </tr>
          <tr>
            <td align="left">last_index</td>
            <td align="left">N</td>
            <td align="left">The 'index' value of the most recently added series item in an update collection</td>
            <td align="left">LB = 0 <br/><br/> UB = MAX_INDEX</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="sec-RS-examples">
      <name>Interaction Examples</name>
      <t>This section provides examples of interactions between an RS as a registered device and an AS. In the examples, all the access tokens issued by the AS are intended to be consumed by the considered RS.</t>
      <t>The AS supports both full queries and diff queries of the TRL, as defined in Sections <xref target="ssec-trl-full-query"/> target="ssec-trl-full-query" format="counter"/> and <xref target="ssec-trl-diff-query"/>, target="ssec-trl-diff-query" format="counter"/>, respectively.</t>
      <t>Registration is assumed to be done by the RS sending a POST request with an unspecified payload to the AS, which replies with a 2.01 (Created) response. The payload of the registration response is assumed to be a CBOR map, which which, in turn turn, is assumed to include the following entries:</t>
      <ul spacing="normal">
        <li>
          <t>a 'trl_path' parameter, parameter specifying the path of the TRL endpoint;</t>
        </li>
        <li>
          <t>a 'trl_hash' parameter, parameter specifying the "Hash Name String" of the hash function used to compute token hashes as defined in <xref target="sec-token-name"/>;</t>
        </li>
        <li>
          <t>a 'max_n' parameter, parameter specifying the value of MAX_N, i.e., the maximum number of series items that the AS retains in the update collection associated with a registered device (see <xref target="ssec-trl-diff-query"/>);</t>
        </li>
        <li>
          <t>possible further parameters related to the registration process.</t>
        </li>
      </ul>
      <t>Furthermore, 'h(x)' refers to the hash function used to compute the token hashes, as defined in <xref target="sec-token-name"/> of this specification and according to <xref target="RFC6920"/>. Assuming the usage of CWTs transported in AS-to-Client responses encoded in CBOR (see <xref target="sec-token-hash-input-c-as-cbor"/>), 'bstr.h(t1)' and 'bstr.h(t2)' denote the CBOR byte strings with value the token hashes of the access tokens t1 and t2, respectively.</t>
      <section anchor="sec-RS-example-1">
        <name>Full Query with Observe</name>
        <t><xref target="fig-RS-AS"/> shows an interaction example considering a CoAP observation and a full query of the TRL.</t>
        <t>In this example, the AS does not support the "Cursor" extension. Hence, the 'cursor' parameter is not included in the payload of the responses to a full query request.</t>
        <figure anchor="fig-RS-AS">
          <name>Interaction for full query Full Query with Observe</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="1296" width="440" viewBox="0 0 440 1296" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,48 L 8,1280" fill="none" stroke="black"/>
                <path d="M 432,48 L 432,1280" fill="none" stroke="black"/>
                <path d="M 8,80 L 424,80" fill="none" stroke="black"/>
                <path d="M 16,112 L 432,112" fill="none" stroke="black"/>
                <path d="M 8,288 L 424,288" fill="none" stroke="black"/>
                <path d="M 16,320 L 432,320" fill="none" stroke="black"/>
                <path d="M 16,592 L 432,592" fill="none" stroke="black"/>
                <path d="M 16,784 L 432,784" fill="none" stroke="black"/>
                <path d="M 16,976 L 432,976" fill="none" stroke="black"/>
                <path d="M 16,1168 L 432,1168" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="432,288 420,282.4 420,293.6" fill="black" transform="rotate(0,424,288)"/>
                <polygon class="arrowhead" points="432,80 420,74.4 420,85.6" fill="black" transform="rotate(0,424,80)"/>
                <polygon class="arrowhead" points="24,1168 12,1162.4 12,1173.6" fill="black" transform="rotate(180,16,1168)"/>
                <polygon class="arrowhead" points="24,976 12,970.4 12,981.6" fill="black" transform="rotate(180,16,976)"/>
                <polygon class="arrowhead" points="24,784 12,778.4 12,789.6" fill="black" transform="rotate(180,16,784)"/>
                <polygon class="arrowhead" points="24,592 12,586.4 12,597.6" fill="black" transform="rotate(180,16,592)"/>
                <polygon class="arrowhead" points="24,320 12,314.4 12,325.6" fill="black" transform="rotate(180,16,320)"/>
                <polygon class="arrowhead" points="24,112 12,106.4 12,117.6" fill="black" transform="rotate(180,16,112)"/>
                <g class="text">
                  <text x="12" y="36">RS</text>
                  <text x="428" y="36">AS</text>
                  <text x="80" y="68">Registration:</text>
                  <text x="156" y="68">POST</text>
                  <text x="180" y="132">2.01</text>
                  <text x="232" y="132">Created</text>
                  <text x="212" y="148">Payload:</text>
                  <text x="256" y="148">{</text>
                  <text x="200" y="164">/</text>
                  <text x="224" y="164">...</text>
                  <text x="248" y="164">/</text>
                  <text x="236" y="180">"trl_path"</text>
                  <text x="288" y="180">:</text>
                  <text x="356" y="180">"/revoke/trl",</text>
                  <text x="236" y="196">"trl_hash"</text>
                  <text x="288" y="196">:</text>
                  <text x="340" y="196">"sha-256",</text>
                  <text x="248" y="212">"max_n"</text>
                  <text x="288" y="212">:</text>
                  <text x="308" y="212">10</text>
                  <text x="184" y="228">}</text>
                  <text x="40" y="260">GET</text>
                  <text x="192" y="260">coap://as.example.com/revoke/trl/</text>
                  <text x="76" y="276">Observe:</text>
                  <text x="120" y="276">0</text>
                  <text x="76" y="340">2.05</text>
                  <text x="128" y="340">Content</text>
                  <text x="108" y="356">Observe:</text>
                  <text x="156" y="356">42</text>
                  <text x="136" y="372">Content-Format:</text>
                  <text x="300" y="372">application/ace-trl+cbor</text>
                  <text x="108" y="388">Payload:</text>
                  <text x="152" y="388">{</text>
                  <text x="136" y="404">e'full_set'</text>
                  <text x="192" y="404">:</text>
                  <text x="212" y="404">[]</text>
                  <text x="80" y="420">}</text>
                  <text x="216" y="452">...</text>
                  <text x="120" y="484">(Access</text>
                  <text x="180" y="484">tokens</text>
                  <text x="220" y="484">t1</text>
                  <text x="248" y="484">and</text>
                  <text x="276" y="484">t2</text>
                  <text x="316" y="484">issued</text>
                  <text x="104" y="500">and</text>
                  <text x="172" y="500">successfully</text>
                  <text x="264" y="500">submitted</text>
                  <text x="316" y="500">to</text>
                  <text x="344" y="500">RS)</text>
                  <text x="216" y="532">...</text>
                  <text x="144" y="564">(Access</text>
                  <text x="200" y="564">token</text>
                  <text x="236" y="564">t1</text>
                  <text x="260" y="564">is</text>
                  <text x="308" y="564">revoked)</text>
                  <text x="76" y="612">2.05</text>
                  <text x="128" y="612">Content</text>
                  <text x="108" y="628">Observe:</text>
                  <text x="156" y="628">53</text>
                  <text x="136" y="644">Content-Format:</text>
                  <text x="300" y="644">application/ace-trl+cbor</text>
                  <text x="108" y="660">Payload:</text>
                  <text x="152" y="660">{</text>
                  <text x="136" y="676">e'full_set'</text>
                  <text x="192" y="676">:</text>
                  <text x="252" y="676">[bstr.h(t1)]</text>
                  <text x="80" y="692">}</text>
                  <text x="216" y="724">...</text>
                  <text x="144" y="756">(Access</text>
                  <text x="200" y="756">token</text>
                  <text x="236" y="756">t2</text>
                  <text x="260" y="756">is</text>
                  <text x="308" y="756">revoked)</text>
                  <text x="76" y="804">2.05</text>
                  <text x="128" y="804">Content</text>
                  <text x="108" y="820">Observe:</text>
                  <text x="156" y="820">64</text>
                  <text x="136" y="836">Content-Format:</text>
                  <text x="300" y="836">application/ace-trl+cbor</text>
                  <text x="108" y="852">Payload:</text>
                  <text x="152" y="852">{</text>
                  <text x="136" y="868">e'full_set'</text>
                  <text x="192" y="868">:</text>
                  <text x="252" y="868">[bstr.h(t1),</text>
                  <text x="352" y="868">bstr.h(t2)]</text>
                  <text x="80" y="884">}</text>
                  <text x="216" y="916">...</text>
                  <text x="144" y="948">(Access</text>
                  <text x="200" y="948">token</text>
                  <text x="236" y="948">t1</text>
                  <text x="284" y="948">expires)</text>
                  <text x="76" y="996">2.05</text>
                  <text x="128" y="996">Content</text>
                  <text x="108" y="1012">Observe:</text>
                  <text x="156" y="1012">75</text>
                  <text x="136" y="1028">Content-Format:</text>
                  <text x="300" y="1028">application/ace-trl+cbor</text>
                  <text x="108" y="1044">Payload:</text>
                  <text x="152" y="1044">{</text>
                  <text x="136" y="1060">e'full_set'</text>
                  <text x="192" y="1060">:</text>
                  <text x="252" y="1060">[bstr.h(t2)]</text>
                  <text x="80" y="1076">}</text>
                  <text x="216" y="1108">...</text>
                  <text x="144" y="1140">(Access</text>
                  <text x="200" y="1140">token</text>
                  <text x="236" y="1140">t2</text>
                  <text x="284" y="1140">expires)</text>
                  <text x="76" y="1188">2.05</text>
                  <text x="128" y="1188">Content</text>
                  <text x="108" y="1204">Observe:</text>
                  <text x="156" y="1204">86</text>
                  <text x="136" y="1220">Content-Format:</text>
                  <text x="300" y="1220">application/ace-trl+cbor</text>
                  <text x="108" y="1236">Payload:</text>
                  <text x="152" y="1236">{</text>
                  <text x="136" y="1252">e'full_set'</text>
                  <text x="192" y="1252">:</text>
                  <text x="212" y="1252">[]</text>
                  <text x="80" y="1268">}</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
RS                                                  AS
|                                                    |
|  Registration: POST                                |
+--------------------------------------------------->|
|                                                    |
|<---------------------------------------------------+
|                   2.01 Created                     |
|                     Payload: {                     |
|                       / ... /                      |
|                       "trl_path" : "/revoke/trl",  |
|                       "trl_hash" : "sha-256",      |
|                          "max_n" : 10              |
|                     }                              |
|                                                    |
|  GET coap://as.example.com/revoke/trl/             |
|    Observe: 0                                      |
+--------------------------------------------------->|
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 42                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'full_set' : []                          |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|          (Access tokens t1 and t2 issued           |
|          and successfully submitted to RS)         |
|                                                    |
|                        ...                         |
|                                                    |
|             (Access token t1 is revoked)           |
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 53                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'full_set' : [bstr.h(t1)]                |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|             (Access token t2 is revoked)           |
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 64                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'full_set' : [bstr.h(t1), bstr.h(t2)]    |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|             (Access token t1 expires)              |
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 75                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'full_set' : [bstr.h(t2)]                |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|             (Access token t2 expires)              |
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 86                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'full_set' : []                          |
|        }                                           |
|                                                    |
]]></artwork>
          </artset>
        </figure>
      </section>
      <section anchor="sec-RS-example-2">
        <name>Diff Query with Observe</name>
        <t><xref target="fig-RS-AS-2"/> shows an interaction example considering of a CoAP observation and a diff query of the TRL.</t>
        <t>The RS indicates N = 3 as the value of the 'diff' query parameter, i.e., as the maximum number of diff entries to be specified in a response from the AS.</t>
        <t>In this example, the AS does not support the "Cursor" extension. Hence, the 'cursor' parameter and the 'more' parameter are not included in the payload of the responses to a diff query request.</t>
        <figure anchor="fig-RS-AS-2">
          <name>Interaction for diff query Diff Query with Observe</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="1504" width="440" viewBox="0 0 440 1504" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,48 L 8,1488" fill="none" stroke="black"/>
                <path d="M 432,48 L 432,1488" fill="none" stroke="black"/>
                <path d="M 8,80 L 424,80" fill="none" stroke="black"/>
                <path d="M 16,112 L 432,112" fill="none" stroke="black"/>
                <path d="M 8,288 L 424,288" fill="none" stroke="black"/>
                <path d="M 16,320 L 432,320" fill="none" stroke="black"/>
                <path d="M 16,592 L 432,592" fill="none" stroke="black"/>
                <path d="M 16,816 L 432,816" fill="none" stroke="black"/>
                <path d="M 16,1056 L 432,1056" fill="none" stroke="black"/>
                <path d="M 16,1312 L 432,1312" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="432,288 420,282.4 420,293.6" fill="black" transform="rotate(0,424,288)"/>
                <polygon class="arrowhead" points="432,80 420,74.4 420,85.6" fill="black" transform="rotate(0,424,80)"/>
                <polygon class="arrowhead" points="24,1312 12,1306.4 12,1317.6" fill="black" transform="rotate(180,16,1312)"/>
                <polygon class="arrowhead" points="24,1056 12,1050.4 12,1061.6" fill="black" transform="rotate(180,16,1056)"/>
                <polygon class="arrowhead" points="24,816 12,810.4 12,821.6" fill="black" transform="rotate(180,16,816)"/>
                <polygon class="arrowhead" points="24,592 12,586.4 12,597.6" fill="black" transform="rotate(180,16,592)"/>
                <polygon class="arrowhead" points="24,320 12,314.4 12,325.6" fill="black" transform="rotate(180,16,320)"/>
                <polygon class="arrowhead" points="24,112 12,106.4 12,117.6" fill="black" transform="rotate(180,16,112)"/>
                <g class="text">
                  <text x="12" y="36">RS</text>
                  <text x="428" y="36">AS</text>
                  <text x="80" y="68">Registration:</text>
                  <text x="156" y="68">POST</text>
                  <text x="180" y="132">2.01</text>
                  <text x="232" y="132">Created</text>
                  <text x="212" y="148">Payload:</text>
                  <text x="256" y="148">{</text>
                  <text x="200" y="164">/</text>
                  <text x="224" y="164">...</text>
                  <text x="248" y="164">/</text>
                  <text x="236" y="180">"trl_path"</text>
                  <text x="288" y="180">:</text>
                  <text x="356" y="180">"/revoke/trl",</text>
                  <text x="236" y="196">"trl_hash"</text>
                  <text x="288" y="196">:</text>
                  <text x="340" y="196">"sha-256",</text>
                  <text x="248" y="212">"max_n"</text>
                  <text x="288" y="212">:</text>
                  <text x="308" y="212">10</text>
                  <text x="184" y="228">}</text>
                  <text x="40" y="260">GET</text>
                  <text x="216" y="260">coap://as.example.com/revoke/trl?diff=3</text>
                  <text x="76" y="276">Observe:</text>
                  <text x="120" y="276">0</text>
                  <text x="76" y="340">2.05</text>
                  <text x="128" y="340">Content</text>
                  <text x="108" y="356">Observe:</text>
                  <text x="156" y="356">42</text>
                  <text x="136" y="372">Content-Format:</text>
                  <text x="300" y="372">application/ace-trl+cbor</text>
                  <text x="108" y="388">Payload:</text>
                  <text x="152" y="388">{</text>
                  <text x="136" y="404">e'diff_set'</text>
                  <text x="192" y="404">:</text>
                  <text x="212" y="404">[]</text>
                  <text x="80" y="420">}</text>
                  <text x="216" y="452">...</text>
                  <text x="120" y="484">(Access</text>
                  <text x="180" y="484">tokens</text>
                  <text x="220" y="484">t1</text>
                  <text x="248" y="484">and</text>
                  <text x="276" y="484">t2</text>
                  <text x="316" y="484">issued</text>
                  <text x="104" y="500">and</text>
                  <text x="172" y="500">successfully</text>
                  <text x="264" y="500">submitted</text>
                  <text x="316" y="500">to</text>
                  <text x="344" y="500">RS)</text>
                  <text x="216" y="532">...</text>
                  <text x="136" y="564">(Access</text>
                  <text x="192" y="564">token</text>
                  <text x="228" y="564">t1</text>
                  <text x="252" y="564">is</text>
                  <text x="300" y="564">revoked)</text>
                  <text x="76" y="612">2.05</text>
                  <text x="128" y="612">Content</text>
                  <text x="108" y="628">Observe:</text>
                  <text x="156" y="628">53</text>
                  <text x="136" y="644">Content-Format:</text>
                  <text x="300" y="644">application/ace-trl+cbor</text>
                  <text x="108" y="660">Payload:</text>
                  <text x="152" y="660">{</text>
                  <text x="136" y="676">e'diff_set'</text>
                  <text x="192" y="676">:</text>
                  <text x="208" y="676">[</text>
                  <text x="216" y="692">[</text>
                  <text x="240" y="692">[],</text>
                  <text x="308" y="692">[bstr.h(t1)]</text>
                  <text x="368" y="692">]</text>
                  <text x="208" y="708">]</text>
                  <text x="80" y="724">}</text>
                  <text x="216" y="756">...</text>
                  <text x="136" y="788">(Access</text>
                  <text x="192" y="788">token</text>
                  <text x="228" y="788">t2</text>
                  <text x="252" y="788">is</text>
                  <text x="300" y="788">revoked)</text>
                  <text x="76" y="836">2.05</text>
                  <text x="128" y="836">Content</text>
                  <text x="108" y="852">Observe:</text>
                  <text x="156" y="852">64</text>
                  <text x="136" y="868">Content-Format:</text>
                  <text x="300" y="868">application/ace-trl+cbor</text>
                  <text x="108" y="884">Payload:</text>
                  <text x="152" y="884">{</text>
                  <text x="136" y="900">e'diff_set'</text>
                  <text x="192" y="900">:</text>
                  <text x="208" y="900">[</text>
                  <text x="216" y="916">[</text>
                  <text x="240" y="916">[],</text>
                  <text x="308" y="916">[bstr.h(t2)]</text>
                  <text x="372" y="916">],</text>
                  <text x="216" y="932">[</text>
                  <text x="240" y="932">[],</text>
                  <text x="308" y="932">[bstr.h(t1)]</text>
                  <text x="368" y="932">]</text>
                  <text x="208" y="948">]</text>
                  <text x="80" y="964">}</text>
                  <text x="216" y="996">...</text>
                  <text x="152" y="1028">(Access</text>
                  <text x="208" y="1028">token</text>
                  <text x="244" y="1028">t1</text>
                  <text x="292" y="1028">expires)</text>
                  <text x="76" y="1076">2.05</text>
                  <text x="128" y="1076">Content</text>
                  <text x="108" y="1092">Observe:</text>
                  <text x="156" y="1092">75</text>
                  <text x="136" y="1108">Content-Format:</text>
                  <text x="300" y="1108">application/ace-trl+cbor</text>
                  <text x="108" y="1124">Payload:</text>
                  <text x="152" y="1124">{</text>
                  <text x="136" y="1140">e'diff_set'</text>
                  <text x="192" y="1140">:</text>
                  <text x="208" y="1140">[</text>
                  <text x="216" y="1156">[</text>
                  <text x="280" y="1156">[bstr.h(t1)],</text>
                  <text x="348" y="1156">[]</text>
                  <text x="372" y="1156">],</text>
                  <text x="216" y="1172">[</text>
                  <text x="240" y="1172">[],</text>
                  <text x="308" y="1172">[bstr.h(t2)]</text>
                  <text x="372" y="1172">],</text>
                  <text x="216" y="1188">[</text>
                  <text x="240" y="1188">[],</text>
                  <text x="308" y="1188">[bstr.h(t1)]</text>
                  <text x="368" y="1188">]</text>
                  <text x="208" y="1204">]</text>
                  <text x="80" y="1220">}</text>
                  <text x="216" y="1252">...</text>
                  <text x="152" y="1284">(Access</text>
                  <text x="208" y="1284">token</text>
                  <text x="244" y="1284">t2</text>
                  <text x="292" y="1284">expires)</text>
                  <text x="76" y="1332">2.05</text>
                  <text x="128" y="1332">Content</text>
                  <text x="108" y="1348">Observe:</text>
                  <text x="156" y="1348">86</text>
                  <text x="136" y="1364">Content-Format:</text>
                  <text x="300" y="1364">application/ace-trl+cbor</text>
                  <text x="108" y="1380">Payload:</text>
                  <text x="152" y="1380">{</text>
                  <text x="136" y="1396">e'diff_set'</text>
                  <text x="192" y="1396">:</text>
                  <text x="208" y="1396">[</text>
                  <text x="216" y="1412">[</text>
                  <text x="280" y="1412">[bstr.h(t2)],</text>
                  <text x="348" y="1412">[]</text>
                  <text x="372" y="1412">],</text>
                  <text x="216" y="1428">[</text>
                  <text x="280" y="1428">[bstr.h(t1)],</text>
                  <text x="348" y="1428">[]</text>
                  <text x="372" y="1428">],</text>
                  <text x="216" y="1444">[</text>
                  <text x="240" y="1444">[],</text>
                  <text x="308" y="1444">[bstr.h(t2)]</text>
                  <text x="368" y="1444">]</text>
                  <text x="208" y="1460">]</text>
                  <text x="80" y="1476">}</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
RS                                                  AS
|                                                    |
|  Registration: POST                                |
+--------------------------------------------------->|
|                                                    |
|<---------------------------------------------------+
|                   2.01 Created                     |
|                     Payload: {                     |
|                       / ... /                      |
|                       "trl_path" : "/revoke/trl",  |
|                       "trl_hash" : "sha-256",      |
|                          "max_n" : 10              |
|                     }                              |
|                                                    |
|  GET coap://as.example.com/revoke/trl?diff=3       |
|    Observe: 0                                      |
+--------------------------------------------------->|
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 42                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'diff_set' : []                          |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|          (Access tokens t1 and t2 issued           |
|          and successfully submitted to RS)         |
|                                                    |
|                        ...                         |
|                                                    |
|            (Access token t1 is revoked)            |
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 53                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'diff_set' : [                           |
|                         [ [], [bstr.h(t1)] ]       |
|                        ]                           |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|            (Access token t2 is revoked)            |
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 64                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'diff_set' : [                           |
|                         [ [], [bstr.h(t2)] ],      |
|                         [ [], [bstr.h(t1)] ]       |
|                        ]                           |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|              (Access token t1 expires)             |
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 75                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'diff_set' : [                           |
|                         [ [bstr.h(t1)], [] ],      |
|                         [ [], [bstr.h(t2)] ],      |
|                         [ [], [bstr.h(t1)] ]       |
|                        ]                           |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|              (Access token t2 expires)             |
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 86                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'diff_set' : [                           |
|                         [ [bstr.h(t2)], [] ],      |
|                         [ [bstr.h(t1)], [] ],      |
|                         [ [], [bstr.h(t2)] ]       |
|                        ]                           |
|        }                                           |
|                                                    |
]]></artwork>
          </artset>
        </figure>
      </section>
      <section anchor="sec-RS-example-3">
        <name>Full Query with Observe plus Plus Diff Query</name>
        <t><xref target="fig-RS-AS-3"/> shows an interaction example considering of a CoAP observation and a full query of the TRL.</t>
        <t>The example also considers shows one of the notifications from the AS to get getting lost in transmission, and thus transmission; thus, it does not reaching reach the RS.</t>
        <t>When this happens, and after a waiting time defined by the application has elapsed, the RS sends a GET request with no Observe Option to the AS, AS to perform a diff query of the TRL. The RS indicates N = 8 as the value of the 'diff' query parameter, i.e., as the maximum number of diff entries to be specified in a response from the AS.</t>
        <t>In this example, the AS does not support the "Cursor" extension. Hence, the 'cursor' parameter is not included in the payload of the responses to a full query request. Also, the 'cursor' parameter and the 'more' parameter are not included in the payload of the responses to a diff query request.</t>
        <figure anchor="fig-RS-AS-3">
          <name>Interaction for full query Full Query with Observe plus diff query</name> Plus Diff Query</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="1632" width="440" viewBox="0 0 440 1632" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,48 L 8,1616" fill="none" stroke="black"/>
                <path d="M 432,48 L 432,1616" fill="none" stroke="black"/>
                <path d="M 8,80 L 424,80" fill="none" stroke="black"/>
                <path d="M 16,112 L 432,112" fill="none" stroke="black"/>
                <path d="M 8,288 L 424,288" fill="none" stroke="black"/>
                <path d="M 16,320 L 432,320" fill="none" stroke="black"/>
                <path d="M 16,592 L 432,592" fill="none" stroke="black"/>
                <path d="M 16,784 L 432,784" fill="none" stroke="black"/>
                <path d="M 16,976 L 432,976" fill="none" stroke="black"/>
                <path d="M 88,1168 L 432,1168" fill="none" stroke="black"/>
                <path d="M 8,1408 L 424,1408" fill="none" stroke="black"/>
                <path d="M 16,1440 L 432,1440" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="432,1408 420,1402.4 420,1413.6" fill="black" transform="rotate(0,424,1408)"/>
                <polygon class="arrowhead" points="432,288 420,282.4 420,293.6" fill="black" transform="rotate(0,424,288)"/>
                <polygon class="arrowhead" points="432,80 420,74.4 420,85.6" fill="black" transform="rotate(0,424,80)"/>
                <polygon class="arrowhead" points="96,1168 84,1162.4 84,1173.6" fill="black" transform="rotate(180,88,1168)"/>
                <polygon class="arrowhead" points="24,1440 12,1434.4 12,1445.6" fill="black" transform="rotate(180,16,1440)"/>
                <polygon class="arrowhead" points="24,976 12,970.4 12,981.6" fill="black" transform="rotate(180,16,976)"/>
                <polygon class="arrowhead" points="24,784 12,778.4 12,789.6" fill="black" transform="rotate(180,16,784)"/>
                <polygon class="arrowhead" points="24,592 12,586.4 12,597.6" fill="black" transform="rotate(180,16,592)"/>
                <polygon class="arrowhead" points="24,320 12,314.4 12,325.6" fill="black" transform="rotate(180,16,320)"/>
                <polygon class="arrowhead" points="24,112 12,106.4 12,117.6" fill="black" transform="rotate(180,16,112)"/>
                <g class="text">
                  <text x="12" y="36">RS</text>
                  <text x="428" y="36">AS</text>
                  <text x="80" y="68">Registration:</text>
                  <text x="156" y="68">POST</text>
                  <text x="180" y="132">2.01</text>
                  <text x="232" y="132">Created</text>
                  <text x="212" y="148">Payload:</text>
                  <text x="256" y="148">{</text>
                  <text x="200" y="164">/</text>
                  <text x="224" y="164">...</text>
                  <text x="248" y="164">/</text>
                  <text x="236" y="180">"trl_path"</text>
                  <text x="288" y="180">:</text>
                  <text x="356" y="180">"/revoke/trl",</text>
                  <text x="236" y="196">"trl_hash"</text>
                  <text x="288" y="196">:</text>
                  <text x="340" y="196">"sha-256",</text>
                  <text x="248" y="212">"max_n"</text>
                  <text x="288" y="212">:</text>
                  <text x="308" y="212">10</text>
                  <text x="184" y="228">}</text>
                  <text x="40" y="260">GET</text>
                  <text x="192" y="260">coap://as.example.com/revoke/trl/</text>
                  <text x="76" y="276">Observe:</text>
                  <text x="120" y="276">0</text>
                  <text x="76" y="340">2.05</text>
                  <text x="128" y="340">Content</text>
                  <text x="108" y="356">Observe:</text>
                  <text x="156" y="356">42</text>
                  <text x="136" y="372">Content-Format:</text>
                  <text x="300" y="372">application/ace-trl+cbor</text>
                  <text x="108" y="388">Payload:</text>
                  <text x="152" y="388">{</text>
                  <text x="136" y="404">e'full_set'</text>
                  <text x="192" y="404">:</text>
                  <text x="212" y="404">[]</text>
                  <text x="80" y="420">}</text>
                  <text x="216" y="452">...</text>
                  <text x="120" y="484">(Access</text>
                  <text x="180" y="484">tokens</text>
                  <text x="220" y="484">t1</text>
                  <text x="248" y="484">and</text>
                  <text x="276" y="484">t2</text>
                  <text x="316" y="484">issued</text>
                  <text x="104" y="500">and</text>
                  <text x="172" y="500">successfully</text>
                  <text x="264" y="500">submitted</text>
                  <text x="316" y="500">to</text>
                  <text x="344" y="500">RS)</text>
                  <text x="216" y="532">...</text>
                  <text x="136" y="564">(Access</text>
                  <text x="192" y="564">token</text>
                  <text x="228" y="564">t1</text>
                  <text x="252" y="564">is</text>
                  <text x="300" y="564">revoked)</text>
                  <text x="76" y="612">2.05</text>
                  <text x="128" y="612">Content</text>
                  <text x="108" y="628">Observe:</text>
                  <text x="156" y="628">53</text>
                  <text x="136" y="644">Content-Format:</text>
                  <text x="300" y="644">application/ace-trl+cbor</text>
                  <text x="108" y="660">Payload:</text>
                  <text x="152" y="660">{</text>
                  <text x="136" y="676">e'full_set'</text>
                  <text x="192" y="676">:</text>
                  <text x="252" y="676">[bstr.h(t1)]</text>
                  <text x="80" y="692">}</text>
                  <text x="216" y="724">...</text>
                  <text x="136" y="756">(Access</text>
                  <text x="192" y="756">token</text>
                  <text x="228" y="756">t2</text>
                  <text x="252" y="756">is</text>
                  <text x="300" y="756">revoked)</text>
                  <text x="76" y="804">2.05</text>
                  <text x="128" y="804">Content</text>
                  <text x="108" y="820">Observe:</text>
                  <text x="156" y="820">64</text>
                  <text x="136" y="836">Content-Format:</text>
                  <text x="300" y="836">application/ace-trl+cbor</text>
                  <text x="108" y="852">Payload:</text>
                  <text x="152" y="852">{</text>
                  <text x="136" y="868">e'full_set'</text>
                  <text x="192" y="868">:</text>
                  <text x="252" y="868">[bstr.h(t1),</text>
                  <text x="352" y="868">bstr.h(t2)]</text>
                  <text x="80" y="884">}</text>
                  <text x="216" y="916">...</text>
                  <text x="144" y="948">(Access</text>
                  <text x="200" y="948">token</text>
                  <text x="236" y="948">t1</text>
                  <text x="284" y="948">expires)</text>
                  <text x="76" y="996">2.05</text>
                  <text x="128" y="996">Content</text>
                  <text x="108" y="1012">Observe:</text>
                  <text x="156" y="1012">75</text>
                  <text x="136" y="1028">Content-Format:</text>
                  <text x="300" y="1028">application/ace-trl+cbor</text>
                  <text x="108" y="1044">Payload:</text>
                  <text x="152" y="1044">{</text>
                  <text x="136" y="1060">e'full_set'</text>
                  <text x="192" y="1060">:</text>
                  <text x="252" y="1060">[bstr.h(t2)]</text>
                  <text x="80" y="1076">}</text>
                  <text x="216" y="1108">...</text>
                  <text x="144" y="1140">(Access</text>
                  <text x="200" y="1140">token</text>
                  <text x="236" y="1140">t2</text>
                  <text x="284" y="1140">expires)</text>
                  <text x="44" y="1172">Lost</text>
                  <text x="72" y="1172">X</text>
                  <text x="76" y="1188">2.05</text>
                  <text x="128" y="1188">Content</text>
                  <text x="108" y="1204">Observe:</text>
                  <text x="156" y="1204">86</text>
                  <text x="136" y="1220">Content-Format:</text>
                  <text x="300" y="1220">application/ace-trl+cbor</text>
                  <text x="108" y="1236">Payload:</text>
                  <text x="152" y="1236">{</text>
                  <text x="136" y="1252">e'full_set'</text>
                  <text x="192" y="1252">:</text>
                  <text x="212" y="1252">[]</text>
                  <text x="80" y="1268">}</text>
                  <text x="216" y="1300">...</text>
                  <text x="128" y="1332">(Enough</text>
                  <text x="180" y="1332">time</text>
                  <text x="216" y="1332">has</text>
                  <text x="260" y="1332">passed</text>
                  <text x="312" y="1332">since</text>
                  <text x="96" y="1348">the</text>
                  <text x="140" y="1348">latest</text>
                  <text x="204" y="1348">received</text>
                  <text x="296" y="1348">notification)</text>
                  <text x="40" y="1396">GET</text>
                  <text x="216" y="1396">coap://as.example.com/revoke/trl?diff=8</text>
                  <text x="76" y="1460">2.05</text>
                  <text x="128" y="1460">Content</text>
                  <text x="136" y="1476">Content-Format:</text>
                  <text x="300" y="1476">application/ace-trl+cbor</text>
                  <text x="108" y="1492">Payload:</text>
                  <text x="152" y="1492">{</text>
                  <text x="136" y="1508">e'diff_set'</text>
                  <text x="192" y="1508">:</text>
                  <text x="208" y="1508">[</text>
                  <text x="216" y="1524">[</text>
                  <text x="280" y="1524">[bstr.h(t2)],</text>
                  <text x="348" y="1524">[]</text>
                  <text x="372" y="1524">],</text>
                  <text x="216" y="1540">[</text>
                  <text x="280" y="1540">[bstr.h(t1)],</text>
                  <text x="348" y="1540">[]</text>
                  <text x="372" y="1540">],</text>
                  <text x="216" y="1556">[</text>
                  <text x="240" y="1556">[],</text>
                  <text x="308" y="1556">[bstr.h(t2)]</text>
                  <text x="372" y="1556">],</text>
                  <text x="216" y="1572">[</text>
                  <text x="240" y="1572">[],</text>
                  <text x="308" y="1572">[bstr.h(t1)]</text>
                  <text x="368" y="1572">]</text>
                  <text x="208" y="1588">]</text>
                  <text x="80" y="1604">}</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
RS                                                  AS
|                                                    |
|  Registration: POST                                |
+--------------------------------------------------->|
|                                                    |
|<---------------------------------------------------+
|                   2.01 Created                     |
|                     Payload: {                     |
|                       / ... /                      |
|                       "trl_path" : "/revoke/trl",  |
|                       "trl_hash" : "sha-256",      |
|                          "max_n" : 10              |
|                     }                              |
|                                                    |
|  GET coap://as.example.com/revoke/trl/             |
|    Observe: 0                                      |
+--------------------------------------------------->|
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 42                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'full_set' : []                          |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|          (Access tokens t1 and t2 issued           |
|          and successfully submitted to RS)         |
|                                                    |
|                        ...                         |
|                                                    |
|            (Access token t1 is revoked)            |
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 53                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'full_set' : [bstr.h(t1)]                |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|            (Access token t2 is revoked)            |
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 64                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'full_set' : [bstr.h(t1), bstr.h(t2)]    |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|             (Access token t1 expires)              |
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Observe: 75                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'full_set' : [bstr.h(t2)]                |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|             (Access token t2 expires)              |
|                                                    |
|  Lost X <------------------------------------------+
|      2.05 Content                                  |
|        Observe: 86                                 |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'full_set' : []                          |
|        }                                           |
|                                                    |
|                        ...                         |
|                                                    |
|           (Enough time has passed since            |
|         the latest received notification)          |
|                                                    |
|                                                    |
|  GET coap://as.example.com/revoke/trl?diff=8       |
+--------------------------------------------------->|
|                                                    |
|<---------------------------------------------------+
|      2.05 Content                                  |
|        Content-Format: application/ace-trl+cbor    |
|        Payload: {                                  |
|          e'diff_set' : [                           |
|                         [ [bstr.h(t2)], [] ],      |
|                         [ [bstr.h(t1)], [] ],      |
|                         [ [], [bstr.h(t2)] ],      |
|                         [ [], [bstr.h(t1)] ]       |
|                        ]                           |
|        }                                           |
|                                                    |
]]></artwork>
          </artset>
        </figure>
      </section>
      <section anchor="sec-RS-example-2-3">
        <name>Diff Query with Observe and "Cursor"</name>
        <t>In this example, the AS supports the "Cursor" extension. Hence, the CBOR map conveyed as payload of the registration response additionally includes a "max_diff_batch" parameter. This specifies the value of MAX_DIFF_BATCH, i.e., the maximum number of diff entries that can be included in a response to a diff query request from this RS.</t>
        <t><xref target="fig-RS-AS-4"/> shows an interaction example considering of a CoAP observation and a diff query of the TRL.</t>
        <t>The RS specifies the query parameter 'diff' with a value of 3, i.e., the maximum number of diff entries to be specified in a response from the AS.</t>
        <t>After
        <t>If the RS has not received a notification from the AS for after a waiting time defined by the application, the RS sends a GET request with no Observe Option to the AS, AS to perform a diff query of the TRL.</t>
        <t>This is followed up by a further diff query request that specifies the query parameter 'cursor'. Note that the payload of the corresponding response differs from the payload of the response to the previous diff query request.</t>
        <figure anchor="fig-RS-AS-4">
          <name>Interaction for diff query Diff Query with Observe and "Cursor"</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="2224" width="472" viewBox="0 0 472 2224" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,48 L 8,2208" fill="none" stroke="black"/>
                <path d="M 464,48 L 464,2208" fill="none" stroke="black"/>
                <path d="M 8,80 L 456,80" fill="none" stroke="black"/>
                <path d="M 16,112 L 464,112" fill="none" stroke="black"/>
                <path d="M 8,304 L 456,304" fill="none" stroke="black"/>
                <path d="M 16,336 L 464,336" fill="none" stroke="black"/>
                <path d="M 16,640 L 464,640" fill="none" stroke="black"/>
                <path d="M 16,896 L 464,896" fill="none" stroke="black"/>
                <path d="M 16,1168 L 464,1168" fill="none" stroke="black"/>
                <path d="M 16,1456 L 464,1456" fill="none" stroke="black"/>
                <path d="M 8,1792 L 456,1792" fill="none" stroke="black"/>
                <path d="M 16,1824 L 464,1824" fill="none" stroke="black"/>
                <path d="M 8,2048 L 456,2048" fill="none" stroke="black"/>
                <path d="M 16,2080 L 464,2080" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="464,2048 452,2042.4 452,2053.6" fill="black" transform="rotate(0,456,2048)"/>
                <polygon class="arrowhead" points="464,1792 452,1786.4 452,1797.6" fill="black" transform="rotate(0,456,1792)"/>
                <polygon class="arrowhead" points="464,304 452,298.4 452,309.6" fill="black" transform="rotate(0,456,304)"/>
                <polygon class="arrowhead" points="464,80 452,74.4 452,85.6" fill="black" transform="rotate(0,456,80)"/>
                <polygon class="arrowhead" points="24,2080 12,2074.4 12,2085.6" fill="black" transform="rotate(180,16,2080)"/>
                <polygon class="arrowhead" points="24,1824 12,1818.4 12,1829.6" fill="black" transform="rotate(180,16,1824)"/>
                <polygon class="arrowhead" points="24,1456 12,1450.4 12,1461.6" fill="black" transform="rotate(180,16,1456)"/>
                <polygon class="arrowhead" points="24,1168 12,1162.4 12,1173.6" fill="black" transform="rotate(180,16,1168)"/>
                <polygon class="arrowhead" points="24,896 12,890.4 12,901.6" fill="black" transform="rotate(180,16,896)"/>
                <polygon class="arrowhead" points="24,640 12,634.4 12,645.6" fill="black" transform="rotate(180,16,640)"/>
                <polygon class="arrowhead" points="24,336 12,330.4 12,341.6" fill="black" transform="rotate(180,16,336)"/>
                <polygon class="arrowhead" points="24,112 12,106.4 12,117.6" fill="black" transform="rotate(180,16,112)"/>
                <g class="text">
                  <text x="12" y="36">RS</text>
                  <text x="460" y="36">AS</text>
                  <text x="80" y="68">Registration:</text>
                  <text x="156" y="68">POST</text>
                  <text x="172" y="132">2.01</text>
                  <text x="224" y="132">Created</text>
                  <text x="204" y="148">Payload:</text>
                  <text x="248" y="148">{</text>
                  <text x="232" y="164">/</text>
                  <text x="256" y="164">...</text>
                  <text x="280" y="164">/</text>
                  <text x="268" y="180">"trl_path"</text>
                  <text x="320" y="180">:</text>
                  <text x="388" y="180">"/revoke/trl",</text>
                  <text x="268" y="196">"trl_hash"</text>
                  <text x="320" y="196">:</text>
                  <text x="372" y="196">"sha-256",</text>
                  <text x="280" y="212">"max_n"</text>
                  <text x="320" y="212">:</text>
                  <text x="344" y="212">10,</text>
                  <text x="256" y="228">"max_diff_batch":</text>
                  <text x="336" y="228">5</text>
                  <text x="176" y="244">}</text>
                  <text x="40" y="276">GET</text>
                  <text x="216" y="276">coap://as.example.com/revoke/trl?diff=3</text>
                  <text x="76" y="292">Observe:</text>
                  <text x="120" y="292">0</text>
                  <text x="108" y="356">2.05</text>
                  <text x="160" y="356">Content</text>
                  <text x="140" y="372">Observe:</text>
                  <text x="188" y="372">42</text>
                  <text x="168" y="388">Content-Format:</text>
                  <text x="332" y="388">application/ace-trl+cbor</text>
                  <text x="140" y="404">Payload:</text>
                  <text x="184" y="404">{</text>
                  <text x="168" y="420">e'diff_set'</text>
                  <text x="224" y="420">:</text>
                  <text x="248" y="420">[],</text>
                  <text x="176" y="436">e'cursor'</text>
                  <text x="224" y="436">:</text>
                  <text x="256" y="436">null,</text>
                  <text x="184" y="452">e'more'</text>
                  <text x="224" y="452">:</text>
                  <text x="256" y="452">false</text>
                  <text x="112" y="468">}</text>
                  <text x="232" y="500">...</text>
                  <text x="136" y="532">(Access</text>
                  <text x="196" y="532">tokens</text>
                  <text x="236" y="532">t1</text>
                  <text x="264" y="532">and</text>
                  <text x="292" y="532">t2</text>
                  <text x="332" y="532">issued</text>
                  <text x="120" y="548">and</text>
                  <text x="188" y="548">successfully</text>
                  <text x="280" y="548">submitted</text>
                  <text x="332" y="548">to</text>
                  <text x="360" y="548">RS)</text>
                  <text x="232" y="580">...</text>
                  <text x="152" y="612">(Access</text>
                  <text x="208" y="612">token</text>
                  <text x="244" y="612">t1</text>
                  <text x="268" y="612">is</text>
                  <text x="316" y="612">revoked)</text>
                  <text x="108" y="660">2.05</text>
                  <text x="160" y="660">Content</text>
                  <text x="140" y="676">Observe:</text>
                  <text x="188" y="676">53</text>
                  <text x="168" y="692">Content-Format:</text>
                  <text x="332" y="692">application/ace-trl+cbor</text>
                  <text x="140" y="708">Payload:</text>
                  <text x="184" y="708">{</text>
                  <text x="168" y="724">e'diff_set'</text>
                  <text x="224" y="724">:</text>
                  <text x="240" y="724">[</text>
                  <text x="248" y="740">[</text>
                  <text x="272" y="740">[],</text>
                  <text x="340" y="740">[bstr.h(t1)]</text>
                  <text x="400" y="740">]</text>
                  <text x="244" y="756">],</text>
                  <text x="176" y="772">e'cursor'</text>
                  <text x="224" y="772">:</text>
                  <text x="244" y="772">0,</text>
                  <text x="184" y="788">e'more'</text>
                  <text x="224" y="788">:</text>
                  <text x="256" y="788">false</text>
                  <text x="112" y="804">}</text>
                  <text x="232" y="836">...</text>
                  <text x="152" y="868">(Access</text>
                  <text x="208" y="868">token</text>
                  <text x="244" y="868">t2</text>
                  <text x="268" y="868">is</text>
                  <text x="316" y="868">revoked)</text>
                  <text x="108" y="916">2.05</text>
                  <text x="160" y="916">Content</text>
                  <text x="140" y="932">Observe:</text>
                  <text x="188" y="932">64</text>
                  <text x="168" y="948">Content-Format:</text>
                  <text x="332" y="948">application/ace-trl+cbor</text>
                  <text x="140" y="964">Payload:</text>
                  <text x="184" y="964">{</text>
                  <text x="168" y="980">e'diff_set'</text>
                  <text x="224" y="980">:</text>
                  <text x="240" y="980">[</text>
                  <text x="248" y="996">[</text>
                  <text x="272" y="996">[],</text>
                  <text x="340" y="996">[bstr.h(t2)]</text>
                  <text x="404" y="996">],</text>
                  <text x="248" y="1012">[</text>
                  <text x="272" y="1012">[],</text>
                  <text x="340" y="1012">[bstr.h(t1)]</text>
                  <text x="400" y="1012">]</text>
                  <text x="244" y="1028">],</text>
                  <text x="176" y="1044">e'cursor'</text>
                  <text x="224" y="1044">:</text>
                  <text x="244" y="1044">1,</text>
                  <text x="184" y="1060">e'more'</text>
                  <text x="224" y="1060">:</text>
                  <text x="256" y="1060">false</text>
                  <text x="112" y="1076">}</text>
                  <text x="232" y="1108">...</text>
                  <text x="152" y="1140">(Access</text>
                  <text x="208" y="1140">token</text>
                  <text x="244" y="1140">t1</text>
                  <text x="292" y="1140">expires)</text>
                  <text x="108" y="1188">2.05</text>
                  <text x="160" y="1188">Content</text>
                  <text x="140" y="1204">Observe:</text>
                  <text x="188" y="1204">75</text>
                  <text x="168" y="1220">Content-Format:</text>
                  <text x="332" y="1220">application/ace-trl+cbor</text>
                  <text x="140" y="1236">Payload:</text>
                  <text x="184" y="1236">{</text>
                  <text x="168" y="1252">e'diff_set'</text>
                  <text x="224" y="1252">:</text>
                  <text x="240" y="1252">[</text>
                  <text x="248" y="1268">[</text>
                  <text x="312" y="1268">[bstr.h(t1)],</text>
                  <text x="380" y="1268">[]</text>
                  <text x="404" y="1268">],</text>
                  <text x="248" y="1284">[</text>
                  <text x="272" y="1284">[],</text>
                  <text x="340" y="1284">[bstr.h(t2)]</text>
                  <text x="404" y="1284">],</text>
                  <text x="248" y="1300">[</text>
                  <text x="272" y="1300">[],</text>
                  <text x="340" y="1300">[bstr.h(t1)]</text>
                  <text x="400" y="1300">]</text>
                  <text x="244" y="1316">],</text>
                  <text x="176" y="1332">e'cursor'</text>
                  <text x="224" y="1332">:</text>
                  <text x="244" y="1332">2,</text>
                  <text x="184" y="1348">e'more'</text>
                  <text x="224" y="1348">:</text>
                  <text x="256" y="1348">false</text>
                  <text x="112" y="1364">}</text>
                  <text x="232" y="1396">...</text>
                  <text x="152" y="1428">(Access</text>
                  <text x="208" y="1428">token</text>
                  <text x="244" y="1428">t2</text>
                  <text x="292" y="1428">expires)</text>
                  <text x="108" y="1476">2.05</text>
                  <text x="160" y="1476">Content</text>
                  <text x="140" y="1492">Observe:</text>
                  <text x="188" y="1492">86</text>
                  <text x="168" y="1508">Content-Format:</text>
                  <text x="332" y="1508">application/ace-trl+cbor</text>
                  <text x="140" y="1524">Payload:</text>
                  <text x="184" y="1524">{</text>
                  <text x="168" y="1540">e'diff_set'</text>
                  <text x="224" y="1540">:</text>
                  <text x="240" y="1540">[</text>
                  <text x="248" y="1556">[</text>
                  <text x="312" y="1556">[bstr.h(t2)],</text>
                  <text x="380" y="1556">[]</text>
                  <text x="404" y="1556">],</text>
                  <text x="248" y="1572">[</text>
                  <text x="312" y="1572">[bstr.h(t1)],</text>
                  <text x="380" y="1572">[]</text>
                  <text x="404" y="1572">],</text>
                  <text x="248" y="1588">[</text>
                  <text x="272" y="1588">[],</text>
                  <text x="340" y="1588">[bstr.h(t2)]</text>
                  <text x="400" y="1588">]</text>
                  <text x="244" y="1604">],</text>
                  <text x="176" y="1620">e'cursor'</text>
                  <text x="224" y="1620">:</text>
                  <text x="244" y="1620">3,</text>
                  <text x="184" y="1636">e'more'</text>
                  <text x="224" y="1636">:</text>
                  <text x="256" y="1636">false</text>
                  <text x="112" y="1652">}</text>
                  <text x="232" y="1684">...</text>
                  <text x="136" y="1716">(Enough</text>
                  <text x="188" y="1716">time</text>
                  <text x="224" y="1716">has</text>
                  <text x="268" y="1716">passed</text>
                  <text x="320" y="1716">since</text>
                  <text x="128" y="1732">the</text>
                  <text x="172" y="1732">latest</text>
                  <text x="236" y="1732">received</text>
                  <text x="328" y="1732">notification)</text>
                  <text x="40" y="1780">GET</text>
                  <text x="216" y="1780">coap://as.example.com/revoke/trl?diff=3</text>
                  <text x="108" y="1844">2.05</text>
                  <text x="160" y="1844">Content</text>
                  <text x="168" y="1860">Content-Format:</text>
                  <text x="332" y="1860">application/ace-trl+cbor</text>
                  <text x="140" y="1876">Payload:</text>
                  <text x="184" y="1876">{</text>
                  <text x="168" y="1892">e'diff_set'</text>
                  <text x="224" y="1892">:</text>
                  <text x="240" y="1892">[</text>
                  <text x="248" y="1908">[</text>
                  <text x="312" y="1908">[bstr.h(t2)],</text>
                  <text x="380" y="1908">[]</text>
                  <text x="404" y="1908">],</text>
                  <text x="248" y="1924">[</text>
                  <text x="312" y="1924">[bstr.h(t1)],</text>
                  <text x="380" y="1924">[]</text>
                  <text x="404" y="1924">],</text>
                  <text x="248" y="1940">[</text>
                  <text x="272" y="1940">[],</text>
                  <text x="340" y="1940">[bstr.h(t2)]</text>
                  <text x="400" y="1940">]</text>
                  <text x="244" y="1956">],</text>
                  <text x="176" y="1972">e'cursor'</text>
                  <text x="224" y="1972">:</text>
                  <text x="244" y="1972">3,</text>
                  <text x="184" y="1988">e'more'</text>
                  <text x="224" y="1988">:</text>
                  <text x="256" y="1988">false</text>
                  <text x="112" y="2004">}</text>
                  <text x="40" y="2036">GET</text>
                  <text x="252" y="2036">coap://as.example.com/revoke/trl?diff=3&amp;cursor=3</text>
                  <text x="108" y="2100">2.05</text>
                  <text x="160" y="2100">Content</text>
                  <text x="168" y="2116">Content-Format:</text>
                  <text x="332" y="2116">application/ace-trl+cbor</text>
                  <text x="140" y="2132">Payload:</text>
                  <text x="184" y="2132">{</text>
                  <text x="168" y="2148">e'diff_set'</text>
                  <text x="224" y="2148">:</text>
                  <text x="248" y="2148">[],</text>
                  <text x="176" y="2164">e'cursor'</text>
                  <text x="224" y="2164">:</text>
                  <text x="244" y="2164">3,</text>
                  <text x="184" y="2180">e'more'</text>
                  <text x="224" y="2180">:</text>
                  <text x="256" y="2180">false</text>
                  <text x="112" y="2196">}</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
RS                                                      AS
|                                                        |
|  Registration: POST                                    |
+------------------------------------------------------->|
|                                                        |
|<-------------------------------------------------------+
|                  2.01 Created                          |
|                    Payload: {                          |
|                           / ... /                      |
|                           "trl_path" : "/revoke/trl",  |
|                           "trl_hash" : "sha-256",      |
|                              "max_n" : 10,             |
|                      "max_diff_batch": 5               |
|                    }                                   |
|                                                        |
|  GET coap://as.example.com/revoke/trl?diff=3           |
|    Observe: 0                                          |
+------------------------------------------------------->|
|                                                        |
|<-------------------------------------------------------+
|          2.05 Content                                  |
|            Observe: 42                                 |
|            Content-Format: application/ace-trl+cbor    |
|            Payload: {                                  |
|              e'diff_set' : [],                         |
|                e'cursor' : null,                       |
|                  e'more' : false                       |
|            }                                           |
|                                                        |
|                          ...                           |
|                                                        |
|            (Access tokens t1 and t2 issued             |
|            and successfully submitted to RS)           |
|                                                        |
|                          ...                           |
|                                                        |
|              (Access token t1 is revoked)              |
|                                                        |
|<-------------------------------------------------------+
|          2.05 Content                                  |
|            Observe: 53                                 |
|            Content-Format: application/ace-trl+cbor    |
|            Payload: {                                  |
|              e'diff_set' : [                           |
|                             [ [], [bstr.h(t1)] ]       |
|                            ],                          |
|                e'cursor' : 0,                          |
|                  e'more' : false                       |
|            }                                           |
|                                                        |
|                          ...                           |
|                                                        |
|              (Access token t2 is revoked)              |
|                                                        |
|<-------------------------------------------------------+
|          2.05 Content                                  |
|            Observe: 64                                 |
|            Content-Format: application/ace-trl+cbor    |
|            Payload: {                                  |
|              e'diff_set' : [                           |
|                             [ [], [bstr.h(t2)] ],      |
|                             [ [], [bstr.h(t1)] ]       |
|                            ],                          |
|                e'cursor' : 1,                          |
|                  e'more' : false                       |
|            }                                           |
|                                                        |
|                          ...                           |
|                                                        |
|              (Access token t1 expires)                 |
|                                                        |
|<-------------------------------------------------------+
|          2.05 Content                                  |
|            Observe: 75                                 |
|            Content-Format: application/ace-trl+cbor    |
|            Payload: {                                  |
|              e'diff_set' : [                           |
|                             [ [bstr.h(t1)], [] ],      |
|                             [ [], [bstr.h(t2)] ],      |
|                             [ [], [bstr.h(t1)] ]       |
|                            ],                          |
|                e'cursor' : 2,                          |
|                  e'more' : false                       |
|            }                                           |
|                                                        |
|                          ...                           |
|                                                        |
|              (Access token t2 expires)                 |
|                                                        |
|<-------------------------------------------------------+
|          2.05 Content                                  |
|            Observe: 86                                 |
|            Content-Format: application/ace-trl+cbor    |
|            Payload: {                                  |
|              e'diff_set' : [                           |
|                             [ [bstr.h(t2)], [] ],      |
|                             [ [bstr.h(t1)], [] ],      |
|                             [ [], [bstr.h(t2)] ]       |
|                            ],                          |
|                e'cursor' : 3,                          |
|                  e'more' : false                       |
|            }                                           |
|                                                        |
|                          ...                           |
|                                                        |
|            (Enough time has passed since               |
|             the latest received notification)          |
|                                                        |
|                                                        |
|  GET coap://as.example.com/revoke/trl?diff=3           |
+------------------------------------------------------->|
|                                                        |
|<-------------------------------------------------------+
|          2.05 Content                                  |
|            Content-Format: application/ace-trl+cbor    |
|            Payload: {                                  |
|              e'diff_set' : [                           |
|                             [ [bstr.h(t2)], [] ],      |
|                             [ [bstr.h(t1)], [] ],      |
|                             [ [], [bstr.h(t2)] ]       |
|                            ],                          |
|                e'cursor' : 3,                          |
|                  e'more' : false                       |
|            }                                           |
|                                                        |
|  GET coap://as.example.com/revoke/trl?diff=3&cursor=3  |
+------------------------------------------------------->|
|                                                        |
|<-------------------------------------------------------+
|          2.05 Content                                  |
|            Content-Format: application/ace-trl+cbor    |
|            Payload: {                                  |
|              e'diff_set' : [],                         |
|                e'cursor' : 3,                          |
|                  e'more' : false                       |
|            }                                           |
|                                                        |
]]></artwork>
          </artset>
        </figure>
      </section>
      <section anchor="sec-RS-example-5">
        <name>Full Query with Observe plus Plus Diff Query with "Cursor"</name>
        <t>In this example, the AS supports the "Cursor" extension. Hence, the CBOR map conveyed as payload of the registration response additionally includes a "max_diff_batch" parameter. This specifies the value of MAX_DIFF_BATCH, i.e., the maximum number of diff entries that can be included in a response to a diff query request from this RS.</t>
        <t><xref target="fig-RS-AS-5"/> shows an interaction example considering of a CoAP observation and a full query of the TRL.</t>
        <t>The example also considers shows some of the notifications from the AS to get getting lost in transmission, and thus transmission; thus, they do not reaching reach the RS.</t>
        <t>When this happens, and after a waiting time defined by the application has elapsed, the RS sends a GET request with no Observe Option to the AS, to perform a diff query of the TRL. In particular, the RS specifies:</t>
        <ul spacing="normal">
          <li>
            <t>The query parameter 'diff' with a value of 8, i.e., the maximum number of diff entries to be specified in a response from the AS.</t>
          </li>
          <li>
            <t>The query parameter 'cursor' with a value of 2, thus requesting from the update collection the series items following the one with the 'index' value equal to 2 (i.e., following the last series item that the RS successfully received in an earlier notification response).</t>
          </li>
        </ul>
        <t>The response from the AS conveys a first batch of MAX_DIFF_BATCH = 5 series items from the update collection corresponding to the RS. The AS indicates that further series items are actually available in the update collection, collection by setting the 'more' parameter of the response to <tt>true</tt>. Also, the 'cursor' parameter of the response is set to 7, i.e., to the 'index' value of the most recent series item included in the response.</t>
        <t>After that, the RS follows up with a further diff query request specifying the query parameter 'cursor' with a value 7, of 7 in order to retrieve the next and last batch of series items from the update collection.</t>
        <figure anchor="fig-RS-AS-5">
          <name>Interaction for full query Full Query with Observe plus diff query Plus Diff Query with "Cursor"</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="3568" width="528" viewBox="0 0 528 3568" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,48 L 8,3552" fill="none" stroke="black"/>
                <path d="M 520,48 L 520,3552" fill="none" stroke="black"/>
                <path d="M 8,80 L 512,80" fill="none" stroke="black"/>
                <path d="M 16,112 L 520,112" fill="none" stroke="black"/>
                <path d="M 8,304 L 512,304" fill="none" stroke="black"/>
                <path d="M 16,336 L 520,336" fill="none" stroke="black"/>
                <path d="M 16,704 L 520,704" fill="none" stroke="black"/>
                <path d="M 16,912 L 520,912" fill="none" stroke="black"/>
                <path d="M 16,1120 L 520,1120" fill="none" stroke="black"/>
                <path d="M 88,1328 L 520,1328" fill="none" stroke="black"/>
                <path d="M 88,1536 L 520,1536" fill="none" stroke="black"/>
                <path d="M 88,1744 L 520,1744" fill="none" stroke="black"/>
                <path d="M 88,1952 L 520,1952" fill="none" stroke="black"/>
                <path d="M 88,2160 L 520,2160" fill="none" stroke="black"/>
                <path d="M 88,2368 L 520,2368" fill="none" stroke="black"/>
                <path d="M 88,2576 L 520,2576" fill="none" stroke="black"/>
                <path d="M 88,2784 L 520,2784" fill="none" stroke="black"/>
                <path d="M 8,3040 L 512,3040" fill="none" stroke="black"/>
                <path d="M 16,3072 L 520,3072" fill="none" stroke="black"/>
                <path d="M 8,3328 L 512,3328" fill="none" stroke="black"/>
                <path d="M 16,3360 L 520,3360" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="520,3328 508,3322.4 508,3333.6" fill="black" transform="rotate(0,512,3328)"/>
                <polygon class="arrowhead" points="520,3040 508,3034.4 508,3045.6" fill="black" transform="rotate(0,512,3040)"/>
                <polygon class="arrowhead" points="520,304 508,298.4 508,309.6" fill="black" transform="rotate(0,512,304)"/>
                <polygon class="arrowhead" points="520,80 508,74.4 508,85.6" fill="black" transform="rotate(0,512,80)"/>
                <polygon class="arrowhead" points="96,2784 84,2778.4 84,2789.6" fill="black" transform="rotate(180,88,2784)"/>
                <polygon class="arrowhead" points="96,2576 84,2570.4 84,2581.6" fill="black" transform="rotate(180,88,2576)"/>
                <polygon class="arrowhead" points="96,2368 84,2362.4 84,2373.6" fill="black" transform="rotate(180,88,2368)"/>
                <polygon class="arrowhead" points="96,2160 84,2154.4 84,2165.6" fill="black" transform="rotate(180,88,2160)"/>
                <polygon class="arrowhead" points="96,1952 84,1946.4 84,1957.6" fill="black" transform="rotate(180,88,1952)"/>
                <polygon class="arrowhead" points="96,1744 84,1738.4 84,1749.6" fill="black" transform="rotate(180,88,1744)"/>
                <polygon class="arrowhead" points="96,1536 84,1530.4 84,1541.6" fill="black" transform="rotate(180,88,1536)"/>
                <polygon class="arrowhead" points="96,1328 84,1322.4 84,1333.6" fill="black" transform="rotate(180,88,1328)"/>
                <polygon class="arrowhead" points="24,3360 12,3354.4 12,3365.6" fill="black" transform="rotate(180,16,3360)"/>
                <polygon class="arrowhead" points="24,3072 12,3066.4 12,3077.6" fill="black" transform="rotate(180,16,3072)"/>
                <polygon class="arrowhead" points="24,1120 12,1114.4 12,1125.6" fill="black" transform="rotate(180,16,1120)"/>
                <polygon class="arrowhead" points="24,912 12,906.4 12,917.6" fill="black" transform="rotate(180,16,912)"/>
                <polygon class="arrowhead" points="24,704 12,698.4 12,709.6" fill="black" transform="rotate(180,16,704)"/>
                <polygon class="arrowhead" points="24,336 12,330.4 12,341.6" fill="black" transform="rotate(180,16,336)"/>
                <polygon class="arrowhead" points="24,112 12,106.4 12,117.6" fill="black" transform="rotate(180,16,112)"/>
                <g class="text">
                  <text x="12" y="36">RS</text>
                  <text x="516" y="36">AS</text>
                  <text x="80" y="68">Registration:</text>
                  <text x="156" y="68">POST</text>
                  <text x="228" y="132">2.01</text>
                  <text x="280" y="132">Created</text>
                  <text x="260" y="148">Payload:</text>
                  <text x="304" y="148">{</text>
                  <text x="288" y="164">/</text>
                  <text x="312" y="164">...</text>
                  <text x="336" y="164">/</text>
                  <text x="324" y="180">"trl_path"</text>
                  <text x="376" y="180">:</text>
                  <text x="444" y="180">"/revoke/trl",</text>
                  <text x="324" y="196">"trl_hash"</text>
                  <text x="376" y="196">:</text>
                  <text x="428" y="196">"sha-256",</text>
                  <text x="336" y="212">"max_n"</text>
                  <text x="376" y="212">:</text>
                  <text x="400" y="212">10,</text>
                  <text x="312" y="228">"max_diff_batch":</text>
                  <text x="392" y="228">5</text>
                  <text x="232" y="244">}</text>
                  <text x="40" y="276">GET</text>
                  <text x="192" y="276">coap://as.example.com/revoke/trl/</text>
                  <text x="76" y="292">Observe:</text>
                  <text x="120" y="292">0</text>
                  <text x="164" y="356">2.05</text>
                  <text x="216" y="356">Content</text>
                  <text x="196" y="372">Observe:</text>
                  <text x="244" y="372">42</text>
                  <text x="224" y="388">Content-Format:</text>
                  <text x="388" y="388">application/ace-trl+cbor</text>
                  <text x="196" y="404">Payload:</text>
                  <text x="240" y="404">{</text>
                  <text x="224" y="420">e'full_set'</text>
                  <text x="280" y="420">:</text>
                  <text x="304" y="420">[],</text>
                  <text x="232" y="436">e'cursor'</text>
                  <text x="280" y="436">:</text>
                  <text x="308" y="436">null</text>
                  <text x="168" y="452">}</text>
                  <text x="264" y="484">...</text>
                  <text x="160" y="516">(Access</text>
                  <text x="220" y="516">tokens</text>
                  <text x="264" y="516">t1,</text>
                  <text x="296" y="516">t2,</text>
                  <text x="324" y="516">t3</text>
                  <text x="364" y="516">issued</text>
                  <text x="152" y="532">and</text>
                  <text x="220" y="532">successfully</text>
                  <text x="312" y="532">submitted</text>
                  <text x="364" y="532">to</text>
                  <text x="392" y="532">RS)</text>
                  <text x="264" y="564">...</text>
                  <text x="160" y="596">(Access</text>
                  <text x="220" y="596">tokens</text>
                  <text x="264" y="596">t4,</text>
                  <text x="296" y="596">t5,</text>
                  <text x="324" y="596">t6</text>
                  <text x="364" y="596">issued</text>
                  <text x="144" y="612">and</text>
                  <text x="212" y="612">successfully</text>
                  <text x="304" y="612">submitted</text>
                  <text x="356" y="612">to</text>
                  <text x="384" y="612">RS)</text>
                  <text x="264" y="644">...</text>
                  <text x="184" y="676">(Access</text>
                  <text x="240" y="676">token</text>
                  <text x="276" y="676">t1</text>
                  <text x="300" y="676">is</text>
                  <text x="348" y="676">revoked)</text>
                  <text x="164" y="724">2.05</text>
                  <text x="216" y="724">Content</text>
                  <text x="196" y="740">Observe:</text>
                  <text x="244" y="740">53</text>
                  <text x="224" y="756">Content-Format:</text>
                  <text x="388" y="756">application/ace-trl+cbor</text>
                  <text x="196" y="772">Payload:</text>
                  <text x="240" y="772">{</text>
                  <text x="224" y="788">e'full_set'</text>
                  <text x="280" y="788">:</text>
                  <text x="344" y="788">[bstr.h(t1)],</text>
                  <text x="232" y="804">e'cursor'</text>
                  <text x="280" y="804">:</text>
                  <text x="296" y="804">0</text>
                  <text x="168" y="820">}</text>
                  <text x="264" y="852">...</text>
                  <text x="184" y="884">(Access</text>
                  <text x="240" y="884">token</text>
                  <text x="276" y="884">t2</text>
                  <text x="300" y="884">is</text>
                  <text x="348" y="884">revoked)</text>
                  <text x="164" y="932">2.05</text>
                  <text x="216" y="932">Content</text>
                  <text x="196" y="948">Observe:</text>
                  <text x="244" y="948">64</text>
                  <text x="224" y="964">Content-Format:</text>
                  <text x="388" y="964">application/ace-trl+cbor</text>
                  <text x="196" y="980">Payload:</text>
                  <text x="240" y="980">{</text>
                  <text x="224" y="996">e'full_set'</text>
                  <text x="280" y="996">:</text>
                  <text x="340" y="996">[bstr.h(t1),</text>
                  <text x="444" y="996">bstr.h(t2)],</text>
                  <text x="232" y="1012">e'cursor'</text>
                  <text x="280" y="1012">:</text>
                  <text x="296" y="1012">1</text>
                  <text x="168" y="1028">}</text>
                  <text x="264" y="1060">...</text>
                  <text x="192" y="1092">(Access</text>
                  <text x="248" y="1092">token</text>
                  <text x="284" y="1092">t1</text>
                  <text x="332" y="1092">expires)</text>
                  <text x="164" y="1140">2.05</text>
                  <text x="216" y="1140">Content</text>
                  <text x="196" y="1156">Observe:</text>
                  <text x="244" y="1156">75</text>
                  <text x="224" y="1172">Content-Format:</text>
                  <text x="388" y="1172">application/ace-trl+cbor</text>
                  <text x="196" y="1188">Payload:</text>
                  <text x="240" y="1188">{</text>
                  <text x="224" y="1204">e'full_set'</text>
                  <text x="280" y="1204">:</text>
                  <text x="344" y="1204">[bstr.h(t2)],</text>
                  <text x="216" y="1220">e'cursor'</text>
                  <text x="280" y="1220">:</text>
                  <text x="296" y="1220">2</text>
                  <text x="168" y="1236">}</text>
                  <text x="264" y="1268">...</text>
                  <text x="192" y="1300">(Access</text>
                  <text x="248" y="1300">token</text>
                  <text x="284" y="1300">t2</text>
                  <text x="332" y="1300">expires)</text>
                  <text x="44" y="1332">Lost</text>
                  <text x="72" y="1332">X</text>
                  <text x="164" y="1348">2.05</text>
                  <text x="216" y="1348">Content</text>
                  <text x="196" y="1364">Observe:</text>
                  <text x="244" y="1364">86</text>
                  <text x="224" y="1380">Content-Format:</text>
                  <text x="388" y="1380">application/ace-trl+cbor</text>
                  <text x="196" y="1396">Payload:</text>
                  <text x="240" y="1396">{</text>
                  <text x="224" y="1412">e'full_set'</text>
                  <text x="280" y="1412">:</text>
                  <text x="304" y="1412">[],</text>
                  <text x="232" y="1428">e'cursor'</text>
                  <text x="280" y="1428">:</text>
                  <text x="296" y="1428">3</text>
                  <text x="168" y="1444">}</text>
                  <text x="264" y="1476">...</text>
                  <text x="184" y="1508">(Access</text>
                  <text x="240" y="1508">token</text>
                  <text x="276" y="1508">t3</text>
                  <text x="300" y="1508">is</text>
                  <text x="348" y="1508">revoked)</text>
                  <text x="44" y="1540">Lost</text>
                  <text x="72" y="1540">X</text>
                  <text x="164" y="1556">2.05</text>
                  <text x="216" y="1556">Content</text>
                  <text x="196" y="1572">Observe:</text>
                  <text x="244" y="1572">88</text>
                  <text x="224" y="1588">Content-Format:</text>
                  <text x="388" y="1588">application/ace-trl+cbor</text>
                  <text x="196" y="1604">Payload:</text>
                  <text x="240" y="1604">{</text>
                  <text x="224" y="1620">e'full_set'</text>
                  <text x="280" y="1620">:</text>
                  <text x="344" y="1620">[bstr.h(t3)],</text>
                  <text x="232" y="1636">e'cursor'</text>
                  <text x="280" y="1636">:</text>
                  <text x="296" y="1636">4</text>
                  <text x="168" y="1652">}</text>
                  <text x="264" y="1684">...</text>
                  <text x="184" y="1716">(Access</text>
                  <text x="240" y="1716">token</text>
                  <text x="276" y="1716">t4</text>
                  <text x="300" y="1716">is</text>
                  <text x="348" y="1716">revoked)</text>
                  <text x="44" y="1748">Lost</text>
                  <text x="72" y="1748">X</text>
                  <text x="164" y="1764">2.05</text>
                  <text x="216" y="1764">Content</text>
                  <text x="196" y="1780">Observe:</text>
                  <text x="244" y="1780">89</text>
                  <text x="224" y="1796">Content-Format:</text>
                  <text x="388" y="1796">application/ace-trl+cbor</text>
                  <text x="196" y="1812">Payload:</text>
                  <text x="240" y="1812">{</text>
                  <text x="224" y="1828">e'full_set'</text>
                  <text x="280" y="1828">:</text>
                  <text x="340" y="1828">[bstr.h(t3),</text>
                  <text x="444" y="1828">bstr.h(t4)],</text>
                  <text x="232" y="1844">e'cursor'</text>
                  <text x="280" y="1844">:</text>
                  <text x="296" y="1844">5</text>
                  <text x="168" y="1860">}</text>
                  <text x="264" y="1892">...</text>
                  <text x="200" y="1924">(Access</text>
                  <text x="256" y="1924">token</text>
                  <text x="292" y="1924">t3</text>
                  <text x="340" y="1924">expires)</text>
                  <text x="44" y="1956">Lost</text>
                  <text x="72" y="1956">X</text>
                  <text x="164" y="1972">2.05</text>
                  <text x="216" y="1972">Content</text>
                  <text x="196" y="1988">Observe:</text>
                  <text x="244" y="1988">90</text>
                  <text x="224" y="2004">Content-Format:</text>
                  <text x="388" y="2004">application/ace-trl+cbor</text>
                  <text x="196" y="2020">Payload:</text>
                  <text x="240" y="2020">{</text>
                  <text x="224" y="2036">e'full_set'</text>
                  <text x="280" y="2036">:</text>
                  <text x="344" y="2036">[bstr.h(t4)],</text>
                  <text x="232" y="2052">e'cursor'</text>
                  <text x="280" y="2052">:</text>
                  <text x="296" y="2052">6</text>
                  <text x="168" y="2068">}</text>
                  <text x="264" y="2100">...</text>
                  <text x="200" y="2132">(Access</text>
                  <text x="256" y="2132">token</text>
                  <text x="292" y="2132">t4</text>
                  <text x="340" y="2132">expires)</text>
                  <text x="44" y="2164">Lost</text>
                  <text x="72" y="2164">X</text>
                  <text x="164" y="2180">2.05</text>
                  <text x="216" y="2180">Content</text>
                  <text x="196" y="2196">Observe:</text>
                  <text x="244" y="2196">91</text>
                  <text x="224" y="2212">Content-Format:</text>
                  <text x="388" y="2212">application/ace-trl+cbor</text>
                  <text x="196" y="2228">Payload:</text>
                  <text x="240" y="2228">{</text>
                  <text x="224" y="2244">e'full_set'</text>
                  <text x="280" y="2244">:</text>
                  <text x="304" y="2244">[],</text>
                  <text x="232" y="2260">e'cursor'</text>
                  <text x="280" y="2260">:</text>
                  <text x="296" y="2260">7</text>
                  <text x="168" y="2276">}</text>
                  <text x="264" y="2308">...</text>
                  <text x="152" y="2340">(Access</text>
                  <text x="212" y="2340">tokens</text>
                  <text x="252" y="2340">t5</text>
                  <text x="280" y="2340">and</text>
                  <text x="308" y="2340">t6</text>
                  <text x="336" y="2340">are</text>
                  <text x="388" y="2340">revoked)</text>
                  <text x="44" y="2372">Lost</text>
                  <text x="72" y="2372">X</text>
                  <text x="164" y="2388">2.05</text>
                  <text x="216" y="2388">Content</text>
                  <text x="196" y="2404">Observe:</text>
                  <text x="244" y="2404">92</text>
                  <text x="224" y="2420">Content-Format:</text>
                  <text x="388" y="2420">application/ace-trl+cbor</text>
                  <text x="196" y="2436">Payload:</text>
                  <text x="240" y="2436">{</text>
                  <text x="224" y="2452">e'full_set'</text>
                  <text x="280" y="2452">:</text>
                  <text x="340" y="2452">[bstr.h(t5),</text>
                  <text x="444" y="2452">bstr.h(t6)],</text>
                  <text x="232" y="2468">e'cursor'</text>
                  <text x="280" y="2468">:</text>
                  <text x="296" y="2468">8</text>
                  <text x="168" y="2484">}</text>
                  <text x="264" y="2516">...</text>
                  <text x="200" y="2548">(Access</text>
                  <text x="256" y="2548">token</text>
                  <text x="292" y="2548">t5</text>
                  <text x="340" y="2548">expires)</text>
                  <text x="44" y="2580">Lost</text>
                  <text x="72" y="2580">X</text>
                  <text x="164" y="2596">2.05</text>
                  <text x="216" y="2596">Content</text>
                  <text x="196" y="2612">Observe:</text>
                  <text x="244" y="2612">93</text>
                  <text x="224" y="2628">Content-Format:</text>
                  <text x="388" y="2628">application/ace-trl+cbor</text>
                  <text x="196" y="2644">Payload:</text>
                  <text x="240" y="2644">{</text>
                  <text x="224" y="2660">e'full_set'</text>
                  <text x="280" y="2660">:</text>
                  <text x="344" y="2660">[bstr.h(t6)],</text>
                  <text x="232" y="2676">e'cursor'</text>
                  <text x="280" y="2676">:</text>
                  <text x="296" y="2676">9</text>
                  <text x="168" y="2692">}</text>
                  <text x="264" y="2724">...</text>
                  <text x="200" y="2756">(Access</text>
                  <text x="256" y="2756">token</text>
                  <text x="292" y="2756">t6</text>
                  <text x="340" y="2756">expires)</text>
                  <text x="44" y="2788">Lost</text>
                  <text x="72" y="2788">X</text>
                  <text x="164" y="2804">2.05</text>
                  <text x="216" y="2804">Content</text>
                  <text x="196" y="2820">Observe:</text>
                  <text x="244" y="2820">94</text>
                  <text x="224" y="2836">Content-Format:</text>
                  <text x="388" y="2836">application/ace-trl+cbor</text>
                  <text x="196" y="2852">Payload:</text>
                  <text x="240" y="2852">{</text>
                  <text x="224" y="2868">e'full_set'</text>
                  <text x="280" y="2868">:</text>
                  <text x="304" y="2868">[],</text>
                  <text x="232" y="2884">e'cursor'</text>
                  <text x="280" y="2884">:</text>
                  <text x="300" y="2884">10</text>
                  <text x="168" y="2900">}</text>
                  <text x="264" y="2932">...</text>
                  <text x="168" y="2964">(Enough</text>
                  <text x="220" y="2964">time</text>
                  <text x="256" y="2964">has</text>
                  <text x="300" y="2964">passed</text>
                  <text x="352" y="2964">since</text>
                  <text x="160" y="2980">the</text>
                  <text x="204" y="2980">latest</text>
                  <text x="268" y="2980">received</text>
                  <text x="360" y="2980">notification)</text>
                  <text x="40" y="3028">GET</text>
                  <text x="252" y="3028">coap://as.example.com/revoke/trl?diff=8&amp;cursor=2</text>
                  <text x="164" y="3092">2.05</text>
                  <text x="216" y="3092">Content</text>
                  <text x="224" y="3108">Content-Format:</text>
                  <text x="388" y="3108">application/ace-trl+cbor</text>
                  <text x="196" y="3124">Payload:</text>
                  <text x="240" y="3124">{</text>
                  <text x="224" y="3140">e'diff_set'</text>
                  <text x="280" y="3140">:</text>
                  <text x="296" y="3140">[</text>
                  <text x="304" y="3156">[</text>
                  <text x="368" y="3156">[bstr.h(t4)],</text>
                  <text x="436" y="3156">[]</text>
                  <text x="460" y="3156">],</text>
                  <text x="304" y="3172">[</text>
                  <text x="368" y="3172">[bstr.h(t3)],</text>
                  <text x="436" y="3172">[]</text>
                  <text x="460" y="3172">],</text>
                  <text x="304" y="3188">[</text>
                  <text x="328" y="3188">[],</text>
                  <text x="396" y="3188">[bstr.h(t4)]</text>
                  <text x="460" y="3188">],</text>
                  <text x="304" y="3204">[</text>
                  <text x="328" y="3204">[],</text>
                  <text x="396" y="3204">[bstr.h(t3)]</text>
                  <text x="460" y="3204">],</text>
                  <text x="304" y="3220">[</text>
                  <text x="368" y="3220">[bstr.h(t2)],</text>
                  <text x="436" y="3220">[]</text>
                  <text x="456" y="3220">]</text>
                  <text x="300" y="3236">],</text>
                  <text x="232" y="3252">e'cursor'</text>
                  <text x="280" y="3252">:</text>
                  <text x="300" y="3252">7,</text>
                  <text x="240" y="3268">e'more'</text>
                  <text x="280" y="3268">:</text>
                  <text x="308" y="3268">true</text>
                  <text x="168" y="3284">}</text>
                  <text x="40" y="3316">GET</text>
                  <text x="252" y="3316">coap://as.example.com/revoke/trl?diff=8&amp;cursor=7</text>
                  <text x="92" y="3380">2.05</text>
                  <text x="144" y="3380">Content</text>
                  <text x="152" y="3396">Content-Format:</text>
                  <text x="316" y="3396">application/ace-trl+cbor</text>
                  <text x="124" y="3412">Payload:</text>
                  <text x="168" y="3412">{</text>
                  <text x="152" y="3428">e'diff_set'</text>
                  <text x="208" y="3428">:</text>
                  <text x="224" y="3428">[</text>
                  <text x="232" y="3444">[</text>
                  <text x="296" y="3444">[bstr.h(t6)],</text>
                  <text x="364" y="3444">[]</text>
                  <text x="388" y="3444">],</text>
                  <text x="232" y="3460">[</text>
                  <text x="296" y="3460">[bstr.h(t5)],</text>
                  <text x="364" y="3460">[]</text>
                  <text x="388" y="3460">],</text>
                  <text x="232" y="3476">[</text>
                  <text x="256" y="3476">[],</text>
                  <text x="324" y="3476">[bstr.h(t5),</text>
                  <text x="424" y="3476">bstr.h(t6)]</text>
                  <text x="480" y="3476">]</text>
                  <text x="228" y="3492">],</text>
                  <text x="160" y="3508">e'cursor'</text>
                  <text x="208" y="3508">:</text>
                  <text x="232" y="3508">10,</text>
                  <text x="168" y="3524">e'more'</text>
                  <text x="208" y="3524">:</text>
                  <text x="240" y="3524">false</text>
                  <text x="96" y="3540">}</text>
                </g>
              </svg>
            </artwork>
           <artwork type="ascii-art" align="center"><![CDATA[
RS                                                             AS
|                                                               |
|  Registration: POST                                           |
+-------------------------------------------------------------->|
|                                                               |
|<--------------------------------------------------------------+
|                         2.01 Created                          |
|                           Payload: {                          |
|                                  / ... /                      |
|                                  "trl_path" : "/revoke/trl",  |
|                                  "trl_hash" : "sha-256",      |
|                                     "max_n" : 10,             |
|                             "max_diff_batch": 5               |
|                           }                                   |
|                                                               |
|  GET coap://as.example.com/revoke/trl/                        |
|    Observe: 0                                                 |
+-------------------------------------------------------------->|
|                                                               |
|<--------------------------------------------------------------+
|                 2.05 Content                                  |
|                   Observe: 42                                 |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'full_set' : [],                         |
|                       e'cursor' : null                        |
|                   }                                           |
|                                                               |
|                              ...                              |
|                                                               |
|               (Access tokens t1, t2, t3 issued                |
|                and successfully submitted to RS)              |
|                                                               |
|                              ...                              |
|                                                               |
|               (Access tokens t4, t5, t6 issued                |
|               and successfully submitted to RS)               |
|                                                               |
|                              ...                              |
|                                                               |
|                  (Access token t1 is revoked)                 |
|                                                               |
|<--------------------------------------------------------------+
|                 2.05 Content                                  |
|                   Observe: 53                                 |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'full_set' : [bstr.h(t1)],               |
|                       e'cursor' : 0                           |
|                   }                                           |
|                                                               |
|                              ...                              |
|                                                               |
|                  (Access token t2 is revoked)                 |
|                                                               |
|<--------------------------------------------------------------+
|                 2.05 Content                                  |
|                   Observe: 64                                 |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'full_set' : [bstr.h(t1), bstr.h(t2)],   |
|                       e'cursor' : 1                           |
|                   }                                           |
|                                                               |
|                              ...                              |
|                                                               |
|                   (Access token t1 expires)                   |
|                                                               |
|<--------------------------------------------------------------+
|                 2.05 Content                                  |
|                   Observe: 75                                 |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'full_set' : [bstr.h(t2)],               |
|                     e'cursor'   : 2                           |
|                   }                                           |
|                                                               |
|                              ...                              |
|                                                               |
|                   (Access token t2 expires)                   |
|                                                               |
|  Lost X <-----------------------------------------------------+
|                 2.05 Content                                  |
|                   Observe: 86                                 |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'full_set' : [],                         |
|                       e'cursor' : 3                           |
|                   }                                           |
|                                                               |
|                              ...                              |
|                                                               |
|                  (Access token t3 is revoked)                 |
|                                                               |
|  Lost X <-----------------------------------------------------+
|                 2.05 Content                                  |
|                   Observe: 88                                 |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'full_set' : [bstr.h(t3)],               |
|                       e'cursor' : 4                           |
|                   }                                           |
|                                                               |
|                              ...                              |
|                                                               |
|                  (Access token t4 is revoked)                 |
|                                                               |
|  Lost X <-----------------------------------------------------+
|                 2.05 Content                                  |
|                   Observe: 89                                 |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'full_set' : [bstr.h(t3), bstr.h(t4)],   |
|                       e'cursor' : 5                           |
|                   }                                           |
|                                                               |
|                              ...                              |
|                                                               |
|                    (Access token t3 expires)                  |
|                                                               |
|  Lost X <-----------------------------------------------------+
|                 2.05 Content                                  |
|                   Observe: 90                                 |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'full_set' : [bstr.h(t4)],               |
|                       e'cursor' : 6                           |
|                   }                                           |
|                                                               |
|                              ...                              |
|                                                               |
|                    (Access token t4 expires)                  |
|                                                               |
|  Lost X <-----------------------------------------------------+
|                 2.05 Content                                  |
|                   Observe: 91                                 |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'full_set' : [],                         |
|                       e'cursor' : 7                           |
|                   }                                           |
|                                                               |
|                              ...                              |
|                                                               |
|              (Access tokens t5 and t6 are revoked)            |
|                                                               |
|  Lost X <-----------------------------------------------------+
|                 2.05 Content                                  |
|                   Observe: 92                                 |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'full_set' : [bstr.h(t5), bstr.h(t6)],   |
|                       e'cursor' : 8                           |
|                   }                                           |
|                                                               |
|                              ...                              |
|                                                               |
|                    (Access token t5 expires)                  |
|                                                               |
|  Lost X <-----------------------------------------------------+
|                 2.05 Content                                  |
|                   Observe: 93                                 |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'full_set' : [bstr.h(t6)],               |
|                       e'cursor' : 9                           |
|                   }                                           |
|                                                               |
|                              ...                              |
|                                                               |
|                    (Access token t6 expires)                  |
|                                                               |
|  Lost X <-----------------------------------------------------+
|                 2.05 Content                                  |
|                   Observe: 94                                 |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'full_set' : [],                         |
|                       e'cursor' : 10                          |
|                   }                                           |
|                                                               |
|                              ...                              |
|                                                               |
|                (Enough time has passed since                  |
|                 the latest received notification)             |
|                                                               |
|                                                               |
|  GET coap://as.example.com/revoke/trl?diff=8&cursor=2         |
+-------------------------------------------------------------->|
|                                                               |
|<--------------------------------------------------------------+
|                 2.05 Content                                  |
|                   Content-Format: application/ace-trl+cbor    |
|                   Payload: {                                  |
|                     e'diff_set' : [                           |
|                                    [ [bstr.h(t4)], [] ],      |
|                                    [ [bstr.h(t3)], [] ],      |
|                                    [ [], [bstr.h(t4)] ],      |
|                                    [ [], [bstr.h(t3)] ],      |
|                                    [ [bstr.h(t2)], [] ]       |
|                                   ],                          |
|                       e'cursor' : 7,                          |
|                         e'more' : true                        |
|                   }                                           |
|                                                               |
|  GET coap://as.example.com/revoke/trl?diff=8&cursor=7         |
+-------------------------------------------------------------->|
|                                                               |
|<--------------------------------------------------------------+
|        2.05 Content                                           |
|          Content-Format: application/ace-trl+cbor             |
|          Payload: {                                           |
|            e'diff_set' : [                                    |
|                           [ [bstr.h(t6)], [] ],               |
|                           [ [bstr.h(t5)], [] ],               |
|                           [ [], [bstr.h(t5), bstr.h(t6)] ]    |
|                          ],                                   |
|              e'cursor' : 10,                                  |
|                e'more' : false                                |
|          }                                                    |
|                                                               |
]]></artwork>
          </artset>
        </figure>
      </section>
</section>

<!-- [rfced] We note that Appendices D and E were tagged "removeInRFC"
     in the XML.  We have removed Appendix E (change log) but left
     Appendix D as it has citations to it in the text.  Please review
     and let us know if any further updates are necessary. -->

<section anchor="sec-cddl-model" removeInRFC="true"> >
      <name>CDDL Model</name>
      <figure anchor="fig-cddl-model">
        <name>CDDL model</name>
        <artwork type="CDDL" align="left"><![CDATA[ Model</name>
        <sourcecode type="CDDL"><![CDATA[
full_set = 0
diff_set = 1
cursor = 2
more = 3

ace-trl-error = 1
]]></artwork>
]]></sourcecode>
      </figure>
    </section>

    <section anchor="sec-document-updates" removeInRFC="true">
      <name>Document Updates</name>
      <section anchor="sec-08-09">
        <name>Version -08 to -09</name>
        <ul spacing="normal">
          <li>
            <t>Terminology:  </t>
            <ul spacing="normal">
              <li>
                <t>Improved definition of "administrator".</t>
              </li>
              <li>
                <t>Added early definitions of "Full query" and "Diff query".</t>
              </li>
            </ul>
          </li>
          <li>
            <t>Rephrased "full TRL" to avoid confusion with "full query".</t>
          </li>
          <li>
            <t>Consistent with RFC 6920, defined sha-256 as mandatory to implement.</t>
          </li>
          <li>
            <t>Prevented an attack to the RS by:  </t>
            <ul spacing="normal">
              <li>
                <t>Using only Protected Headers in access tokens.</t>
              </li>
              <li>
                <t>Using canonical CBOR tagging of CWTs.</t>
              </li>
            </ul>
          </li>
          <li>
            <t>Clarifications:  </t>
            <ul spacing="normal">
              <li>
                <t>Handling of access tokens with 'exi' for both CWTs and JWTs.</t>
              </li>
              <li>
                <t>Registrations of devices are persisted and tracked at the AS.</t>
              </li>
              <li>
                <t>No response or error response from the TRL endpoint yields no assumption.</t>
              </li>
              <li>
                <t>Rationale of application policies in defining strategies and schedules for polling the AS.</t>
              </li>
            </ul>
          </li>
          <li>
            <t>Security considerations:  </t>
            <ul spacing="normal">
              <li>
                <t>Added reference to RFC 8725.</t>
              </li>
              <li>
                <t>Improved considerations on content retrieval from the TRL.</t>
              </li>
            </ul>
          </li>
          <li>
            <t>IANA:  </t>
            <ul spacing="normal">
              <li>
                <t>Added a pointer to where the use of the field 'cursor' in problem-details is defined.</t>
              </li>
              <li>
                <t>Revised text on Expert Review when using early allocation per RFC 7120.</t>
              </li>
            </ul>
          </li>
          <li>
            <t>Split elision and comments in examples with CBOR Diagnostic Notation.</t>
          </li>
          <li>
            <t>Lowercase capitalization for "client", "resource server", and "authorization server".</t>
          </li>
          <li>
            <t>Editorial improvements.</t>
          </li>
        </ul>
      </section>
      <section anchor="sec-07-08">
        <name>Version -07 to -08</name>
        <ul spacing="normal">
          <li>
            <t>Added definition of pertaining token hash.</t>
          </li>
          <li>
            <t>Added definition of pertaining TRL update.</t>
          </li>
          <li>
            <t>Rephrased example of token uploading to be more future ready.</t>
          </li>
          <li>
            <t>Consistent use of "TRL update" throughout the document.</t>
          </li>
          <li>
            <t>Editorial improvements.</t>
          </li>
        </ul>
      </section>
      <section anchor="sec-06-07">
        <name>Version -06 to -07</name>
        <ul spacing="normal">
          <li>
            <t>RFC 9290 is used instead of the custom format for error responses.</t>
          </li>
          <li>
            <t>Avoided quotation marks when using CBOR simple values.</t>
          </li>
          <li>
            <t>CBOR diagnostic notation uses placeholders from a CDDL model.</t>
          </li>
          <li>
            <t>Early mentioning that there is a single MAX_N value.</t>
          </li>
          <li>
            <t>Added more details on the authorization of administrators.</t>
          </li>
          <li>
            <t>Added recommendations for avoiding lost TRL updates from going unnoticed.</t>
          </li>
          <li>
            <t>If diff queries are supported, the AS <bcp14>MUST</bcp14> provide MAX_N at registration.</t>
          </li>
          <li>
            <t>If the "Cursor" extension is supported, the AS <bcp14>MUST</bcp14> provide MAX_DIFF_BATCH at registration.</t>
          </li>
          <li>
            <t>Clarified that how the token revocation specifically happens is out of scope.</t>
          </li>
          <li>
            <t>Clearer, upfront distinction between using CoAP Observe or not.</t>
          </li>
          <li>
            <t>Revised and extended method for computing the token hashes.</t>
          </li>
          <li>
            <t>Clearer presentation of invalid requests to the TRL endpoint.</t>
          </li>
          <li>
            <t>Clearer expected relation between MAX_INDEX and MAX_N values.</t>
          </li>
          <li>
            <t>Clarified meaning of registered parameters.</t>
          </li>
          <li>
            <t>Generalized security considerations on vulnerable time window at the RS.</t>
          </li>
          <li>
            <t>Added security considerations on additional security measures.</t>
          </li>
          <li>
            <t>Fixes and improvements in the IANA considerations.</t>
          </li>
          <li>
            <t>Used AASVG in diagrams.</t>
          </li>
          <li>
            <t>Used actual tables instead of figures.</t>
          </li>
          <li>
            <t>Fixed notation in the examples.</t>
          </li>
          <li>
            <t>Clarifications and editorial improvements.</t>
          </li>
        </ul>
      </section>
      <section anchor="sec-05-06">
        <name>Version -05 to -06</name>
        <ul spacing="normal">
          <li>
            <t>Clarified instructions for Expert Review in the IANA considerations.</t>
          </li>
        </ul>
      </section>
      <section anchor="sec-04-05">
        <name>Version -04 to -05</name>
        <ul spacing="normal">
          <li>
            <t>Explicit focus on CoAP in the abstract and introduction.</t>
          </li>
          <li>
            <t>Removed terminology aliasing ("TRL endpoint" vs. "TRL resource").</t>
          </li>
          <li>
            <t>Use "requester" instead of "caller".</t>
          </li>
          <li>
            <t>Use "subset" instead of "portion".</t>
          </li>
          <li>
            <t>Revised presentation of how token hashes are computed.</t>
          </li>
          <li>
            <t>Improved error handling.</t>
          </li>
          <li>
            <t>Revised examples.</t>
          </li>
          <li>
            <t>More precise security considerations.</t>
          </li>
          <li>
            <t>Clarifications and editorial improvements.</t>
          </li>
          <li>
            <t>Updated author list.</t>
          </li>
        </ul>
      </section>
      <section anchor="sec-03-04">
        <name>Version -03 to -04</name>
        <ul spacing="normal">
          <li>
            <t>Improved presentation of pre- and post-registration operations.</t>
          </li>
          <li>
            <t>Removed moot processing cases with the "Cursor" extension.</t>
          </li>
          <li>
            <t>Positive integers as CBOR abbreviations for all parameters.</t>
          </li>
          <li>
            <t>Renamed N_MAX as MAX_N.</t>
          </li>
          <li>
            <t>Access tokens are not necessarily uploaded through /authz-info.</t>
          </li>
          <li>
            <t>The use of the "c.pmax" conditional attribute is just an example.</t>
          </li>
          <li>
            <t>Revised handling of token hashes at the RS.</t>
          </li>
          <li>
            <t>Extended and improved security considerations.</t>
          </li>
          <li>
            <t>Fixed details in IANA considerations.</t>
          </li>
          <li>
            <t>New appendix overviewing parameters of the TRL endpoint.</t>
          </li>
          <li>
            <t>Examples of message exchange moved to an appendix.</t>
          </li>
          <li>
            <t>Added examples of message exchange with the "Cursor" extension.</t>
          </li>
          <li>
            <t>Clarifications and editorial improvements.</t>
          </li>
        </ul>
      </section>
      <section anchor="sec-02-03">
        <name>Version -02 to -03</name>
        <ul spacing="normal">
          <li>
            <t>Definition of MAX_INDEX for the "Cursor" extension.</t>
          </li>
          <li>
            <t>Handling wrap-around of 'index' when using the "Cursor" extension.</t>
          </li>
          <li>
            <t>Error handling for the case where 'cursor' &gt; MAX_INDEX.</t>
          </li>
          <li>
            <t>Improved error handling in case 'index' is out-of-bound.</t>
          </li>
          <li>
            <t>Clarified parameter semantics, message content and examples.</t>
          </li>
          <li>
            <t>Editorial improvements.</t>
          </li>
        </ul>
      </section>
      <section anchor="sec-01-02">
        <name>Version -01 to -02</name>
        <ul spacing="normal">
          <li>
            <t>Earlier mentioning of error cases.</t>
          </li>
          <li>
            <t>Clearer distinction between maintaining the history of TRL updates and preparing the response to a diff query.</t>
          </li>
          <li>
            <t>Defined the use of "cursor" in the document body, as an extension of diff queries.</t>
          </li>
          <li>
            <t>Both success and error responses have a CBOR map as payload.</t>
          </li>
          <li>
            <t>Corner cases of message processing explained more explicitly.</t>
          </li>
          <li>
            <t>Clarifications and editorial improvements.</t>
          </li>
        </ul>
      </section>
      <section anchor="sec-00-01">
        <name>Version -00 to -01</name>
        <ul spacing="normal">
          <li>
            <t>Added actions to perform upon receiving responses from the TRL endpoint.</t>
          </li>
          <li>
            <t>Fixed off-by-one error when using the "Cursor" pattern.</t>
          </li>
          <li>
            <t>Improved error handling, with registered error codes.</t>
          </li>
          <li>
            <t>Section restructuring (full- and diff-query as self-standing sections).</t>
          </li>
          <li>
            <t>Renamed identifiers and CBOR parameters.</t>
          </li>
          <li>
            <t>Clarifications and editorial improvements.</t>
          </li>
        </ul>
      </section>
    </section>
    <section numbered="false" anchor="acknowldegment">
      <name>Acknowledgments</name>
      <t><contact fullname="Ludwig Seitz"/> contributed as a co-author coauthor of
      initial versions of this document.</t>
      <t>The authors sincerely thank <contact fullname="Christian Amsüss"/>,
      <contact fullname="Carsten Bormann"/>, <contact fullname="Deb Cooley"/>,
      <contact fullname="Roman Danyliw"/>, <contact fullname="Dhruv Dhody"/>,
      <contact fullname="Rikard Höglund"/>, <contact fullname="Benjamin
      Kaduk"/>, <contact fullname="David Navarro"/>, <contact fullname="Joerg
      Ott"/>, <contact fullname="Marco Rasori"/>, <contact fullname="Michael
      Richardson"/>, <contact fullname="Kyle Rose"/>, <contact
      fullname="Zaheduzzaman Sarker"/>, <contact fullname="Jim Schaad"/>,
      <contact fullname="Göran Selander"/>, <contact fullname="Travis
      Spencer"/>, <contact fullname="Orie Steele"/>, <contact fullname="Éric
      Vyncke"/>, <contact fullname="Niklas Widell"/>, <contact fullname="Dale
      Worley"/>, and <contact fullname="Paul Wouters"/> for their comments and
      feedback.</t>
      <t>The work on this document has been partly supported by the Sweden's
      Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and
      CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement
      952652).</t>
    </section>
</back>

<!--[rfced] We had the following questions/comments related to
     abbreviation use throughout the document.

a) After first use with expansion, we will update the following to use
only the abbreviation thereafter unless we hear objection:

RS
AS
CWT

b) We have expanded the following abbreviations on first use.  Please
review and let us know any objections.

IoT
CDDL
CBOR
JWE
JWS
OSCORE
-->

<!--[rfced] We had the following questions regarding terminology used
     throughout the document:

a) Please review the way parameter names are marked with regard to quotation, word order, and the use of simply "parameter" or "query parameter".  For example (there may be more/others), we see:

the 'access_token' parameter / the parameter 'access_token'

the 'diff' query parameter / the query parameter 'diff'

the 'cursor' query parameter / the query parameter 'cursor' / the 'cursor' parameter

Please let us know if/how these may be made uniform throughout.

b) We note that most field names were in single quotes.  We have updated the word order in some places to appear as follows:

'name' field

We also see a few uses of "unprotected" field.  Is this a name?  Or is
this a different use of quotes?  If a name, we suggest matching the
pattern above.  If a different concept, perhaps we can remove the
quotes?

c) We note that we normally see "a 2.05 (Content) response However,
there is one use of "the CoAP response code 2.05 (Content).  Please
review and let us know if/how these should be made uniform.

d) Please review uses of "Cursor".  When double quoted, should it always be followed by the word extension?  Note also that [I-D.bormann-t2trg-stp] uses 'cursor' pattern (single quotes) instead.

Examples below:

Originals:
...as specified in Section 9 in fact relies on the "Cursor" pattern of
the Series Transfer Pattern ...

If supporting "Cursor", then UB = MAX_INDEX+1

...in a diff query response when using "Cursor"

C.4.  Diff Query with Observe and "Cursor"

Figure 13: Interaction for diff query with Observe and "Cursor"

C.5.  Full Query with Observe plus Plus Diff Query with "Cursor"

etc.

e) Will it be clear to the reader what the difference between "hashes"
and "HASHES" is?  Please review these uses and let us know if/how we
may update (perhaps including a citation)?  Should this actually be "a HASHES set" or "a set of
HASHES"?

Uses of HASHES:

   1.  From the TRL, the AS builds a set HASHES such that:

       *  If the requester is a registered device, HASHES specifies the
          token hashes currently in the TRL and associated with the
          access tokens pertaining to that registered device.

f) Please note that we have made several updates related to the use of
the word "occur" throughout the document.  Please review these and let
us know any objections.

g) This document uses both GET request and GET (Observation) request.
Please review and let us know if any updates for consistency are
necessary.

h) Please review the use of "Plus" in section and figure titles and
let us know if "and" or something else is desirable.

i) Please review the use of HASH_INPUT and Hash Input to ensure
satisfaction with the variance.

-->

<!--[rfced] Please consider if it would be helpful for the reader if
     mentions of "step #" were links to the steps in the html version.
     We believe the majority of the instances were pointing to steps
     directly above or below the text in which the pointer existed;
     thus, we have not made any such update (nor do we require it).

An example of how to add this functionality if you so desire:

<ol type="Step %d.">
   <li>...
   <li anchor="step2">...
   <li>...
   </ol>

Following is a list of all such mentions in the current text for your convenience:

       discard the access token yet; instead, it moves to step 4.
   The RS skips step 3 only if it is certain that all its pertaining
   step 3.
   The RS skips step 4 only if it is certain that all its pertaining
   step 4.
       AS moves to step 2.
       considered at step 1.
       step 3.
       because SIZE is equal to 0 at step 2), then no diff entries are
   *  At step 3, the AS considers the value MAX_DIFF_BATCH (see
   *  At step 4, the CBOR map to carry in the payload of the 2.05
            update collection for that requester (see step 5 at
            *  At step 3, the AS considers the value MAX_DIFF_BATCH (see
            *  At step 4, the CBOR map to carry in the payload of the
-->

<!-- [rfced] We updated artwork tags to instead be sourcecode tags in
     the XML formatting of Sections 3, 4.2.1, 4.2.2, 6.1, 7, and
     8. 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/rpc/wiki/doku.php?id=sourcecode-types>.
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.
-->

<!--[rfced] Please review artwork to ensure that it fits within the
     72-character line length limit. -->

<!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is
     output in fixed-width font. In the txt output, there are no
     changes to the font and the quotation marks have been removed.

Please review carefully and let us know if the output is acceptable or
if any updates are needed.

-->

<!--[rfced] Please review cases such as the following knowing that we can use <sub> or <sup> to express mathematical meaning (see https://authors.ietf.org/rfcxml-vocabulary#sup) and let us know if/how we should update:

Original:

   The AS defines the single, constant unsigned integer MAX_INDEX <=
   ((2^64) - 1), where "^" is the exponentiation operator. -->

<!-- ##markdown-source:
H4sIAAAAAAAAA+y96XrbVpYo+l9Pgct890hKkbRIDZaVSnfLkhzLsSVFlCpD
VdoHJEESMQUwAChZ5fg8y3mW+2R3TXsCNkhKcapS1fE5naJIYA9rr73modVq
rd0eBNtra0VcTKOD4Cwt4lE8CIs4TYJ0FFxGt+m7aBgcDgZRngdX8EeSB3ES
FJMoOJzDf5NCPR4mQ/oqzeK/8zejNAuO0iQvsjBOYJST5DbO0uQGXsqDjcOj
k83gRRbeRHdp9m4t7Pez6LZ+CWZueHFtmA4SePMgGGbhqGjFUTFqhYOolfHT
rQKfbiXWWK1pWER5sba29lmQF7DYt+E0TWCEIptHa2vxLKOPedHd2nq21V0L
syg8CHrRYJ7Fxf3a3fgAJw6+hbXGyTj4Kkvns7V3dwfBaVJEWRIVrWNcyhrM
dgATDNfyef8mznOYurifwTynJ1cv1tYG6RBePwjmsOD9tVl8EMC/z4JBmATz
PArCLAvvg414FITTaXAf5ZsBAHES5pNgEmWwziAo0sEB/gIf8zQrsmiUH9AY
w2gUzqcA2iJVv9/f8M/451pIh3OwFtC/lvxvACCFJ960g6t4mg5C/TXD902Y
DdLyT2kGO7g87Z0Eh8/1l3DMUQR7P83D0U9pNszHIYA56Hb1EwMA5EHwdQzg
N9+lQ5ild9Lq7O3sbFlfz5Mig6d7d9EwSvT30U0YTw+CG1xVu6BV/VcWt/PI
v6sX7eACjvmmHydxaWOAeQkg9SD0PEH7O8niQZ4DEnr2eJVm+SS8SdQet3+D
PY7UAtsztcD/imRN7UF6499xrx2cDCbRbZRlcfkse1E/zIsYFux5hPZ89OYa
1nla2e/O7tZW8CIeFZPg8DZK5lFpvxdxUeT9eTaeNIOLw9LGO7vdznaru9fp
Vrd+ncQFXO5egZcTr/vhDe4xLAMjj/SK/yuP4vbgZt6OhnM/DL5qB6+juzgv
bf+rDChE6Zff967HU1yss+G1JM1ugKDdRniRL18cbe91n8nHnb2dffm4t73z
VH18uqMe2Nvf1g88627Jx6cd87G721Uf93Y68nG/u6tGeLrb2TUf98xH9cB+
p6u+3d9+pgbb39nR3+51tszHbfURZlYfn+n1PtvSy3nW0RuClasRnu129823
XfNxW398pp/d2e6UXjsDvBi2T5MRwxTu1UugtO3D6RiYWDG5YVrp0k3CmNPD
Mz7vIZwgXNVwKhRI8VEcOLAGDnDgQA/Mz4bZGNFsUhSz/ODJk7u7uzZczrAN
UzwJgXOMmVU+QfQdtmIzWvWb9vtJcTOFYXsvD1vd3b3alZ+d9q7slRKDi3h5
PWSLYTak33PAyCjHKYBWnl70gs7+Vmvb2jScwn6rs1XZCuxkkGeDdgI0sD1O
b5/M5v2pMOH8ySie8X9oOPPp7ShOwml7NhwBL1b70kj+FHgyfjxtHbeJ1w/S
LIL/JMMYhw2nrbAosrg/h/uknuvjGEnSKrpFNm7lsLC1NRRX4OYinE5evzgI
Gn+FwVvfwb8fG2trrVYrCPsorgxATriaxHkAcsYcDyHIZ9EAZAm4rmFwEwFY
h3hvHyUG+eSgkZKDmsHdJB5MkP2ndzBZIoeoBoNjATKILJ6Em/tgMI1pHJw3
i/J0ngGR46dg8LgdtZvw/RgOA+SHIQgJt/EAxYqwn86LQOSlIGQBj8SmvB0c
5nrDQxb3LFg0adsCBFnnwlXAYmX8kMU4EuoEXq9hZUHKEqV3q/17kIxQ5MIn
bDgezmYKr4KLLAW5KJ0GG0fp4cUmQBGuGb0xS+Em9acw+FAhC0lacHp6oWkf
5+KLBGvLQYrCCTfmSZ7CFEisNwNbmMz5dQ/sgMjfzKYR4Uw4RcmQ8DgIZ7Ms
DYGJAWTneL7yAkC3yFIENo5Lpw9rhblg+J/ncYbrsFYeJcNZGiOkYdOLgN5m
dL6Jh8NphDLvKc4znNM0ICx++Iwm/ri29inE+A8fhC5//BjEeMwan+EMwgKW
DYMM8PIwrODmwuRT3MRpeqWQEn4luANsqph82cs327ALIGNDvgB4ijB7M+in
cNY2MOBZkJkB6vCUwn3GiLr7tHHY26RX+xEcIBxX9c60g3OQx6zvm/AUz0ri
ew5nQ+/9PAc9A6cm6tBr4se0XwDwaHoLWwi08N0lSG0v8KMaz9wYHOOyx1dO
frwBJSWYAYToSfgetIx5CQ+DsNCvMkHBQw5uw2k8JKEjLmCrMD1AuEgJy+Cb
jTyK4Cx7jIzBbruz1e60O6SGqfPdBMw6AWkIBkzn40kJ+wnq0ftZnDF4i/gm
ymn1GSo3sIc4AyqCChgeONxtIXclwNyAFpREsCmARD/SV02WHMM5lyZpqmt1
EGx0Nn3nh1oUDACD4xXNUlDO8AwB7DHeSbqCEVH1foTwsJ76Itjo+sdEsogY
I5oePbq9KfvVE8K5TsJkHGnNGRRJGHuEV51QoDoyjLOzcBwB14wIFICydhzE
6o3dpWsCbkCYD/unMe+DCLBlbkiAb/sbUXsM/CXW74DYAqsi6jeMZnAjiFAN
70FgiQeBZtjahhC9B/mDpogMVWFsh+udEaGI3hd0TPilpgvw0lTuMGIkMKxh
nA/mMD0xLIPEeyX8haGSqWKbIELBekI898ywJDhUEIoy+B0eNHyQiBxKIkDk
ECDnSCaDbnuLf0E5G4cHHQvRSDgaXM2bGWMpEkL3tsBCeRC8GXKLmUzBcqbE
OHAFQK6KYBqPIkT0dvAyvUNVqMlcGf4/cgu4Doy/fGGIXMBCaKEDQ7ybyG+i
7AY0F94e/Jbwi0KEm7xQunzuamll1rqmKdwStSxkOEslJkIjFBjwflWFEltQ
AKQVzg0AmPfzAUh3RM/rRIiNq8vXmwrsSHVji1UI+Z3PhnTWluAsctAsyvAJ
4j7OpgkYd3hzFA2aZXGaCXmPM4sOrSQ2eXaNfOwBso3gIWhqgIewDKQ+8wQf
jozUc9gjENLfQJbgjxTvf5O+JW5lwxTfAPAZ6BmhyycjiURweCFLAU3x40dg
jzhDME8A5tN7fHcmCycoJvwGYjriK/w2ifukBo+AygrNzeezGSC7gh6g77wA
9YQoDPx5T68PoxHBiDF9npunka4ayQNXuUy4Aay9TqbxO00G6dKgZF8Vzqrs
8ZnLGZteGjlMo1xt+TYe4lkE6V1SZthaXqB1x4kW/gg/keMJTULrZRGhKATz
hEOfdB/kMQih9/8YtG+ivBaNRsiGiKTAHpOC70AfCQysOp8h5YdZyJKJfEUI
RgRHmMB5FjmrU3BflGKRRbwKkEuMTF0jNeO5wnMa1Cw7R3U3DnYhmAZv3vvl
azlsIpZJOk3H9yj7BLhkYiDWSzIbrw9PzzMlbkcLh08YInnE1DhkfLIv7yqU
UN1aWWkeDVop8IXbOLpjZIQ38ZlpPJ4UdxH+lyA5L7Rx3ToOJVGHuYuX+jSz
3J5JDOxw11gkRLgAgtOLRqpzcIrv7mAaZsJuEa3gwBERRZfOB+ks0pigKCfg
ekFqxTRP1dP8pKWI6kkFgsOIjw4NbJlwSUbKOtWtiX8CyyBdM3VHQxaKZ0cI
zvcp1wcQLiL7AJvPPguuDBoFn6H2ZeMVQ+8dkLc7tJsHjTfXvatGk/83ODun
z5cn31yfXp4c4+fey8PXr/WHNXmi9/L8+vWx+WTePDp/8+bk7Jhfhm8D56u1
xpvD7xuML43zi6vT87PD143KRvhGEs0lrAUNBIlKmK8NI0ZK2vzzo4v/7/92
dgBN/h+gjN1OB8Ul/mO/83QH/rgDisyz0UXiP5G6r4GSHIUZSbfTKZDiWVzA
mROBASHoLiEfCAD0878iZH48CP7cH8w6O/8hX+CGnS8VzJwvCWbVbyovMxA9
X3mm0dB0vi9B2l3v4ffO3wru1pdra5dA3/HeIeRLAt4IBOppHGaGaiBGMbkA
ZB1EswJVE+tgHscgbdWeDuIugqMJRRr0zEkCIi/z6Pn5ZfBt1Fe+u42jb69y
kV/QOAy4gK++6p2fOY+9Mo+hZRlkC74h1p2htZM1DwVMxbvhkgK5QvISZoMJ
CBcDlB5YSWOZQUvcJbGdLAuzMANAzIFAKdk6GUznAETRFpplswRaJYTQ1loV
2u4xEg17zFnacD0+fi1Q3OvQuRCk+ZtnrIUQUPmb7i59c3TeO5HT3ELZsWmL
cF3rm3OS9CJbuDPMRExnxDhG82TA2hyaI0NUHvs/wcZyxA8L4gxnwCE6ybO0
EM6udho0FNtt4FmRREfK6ihVygIKCHxwNG5sUFOpXWGMJvcQ9U6k9Jboaixu
T8Q2Ant5YiQIZStBpYF+wrP8O1nXjRkFOb9NDLWoYaR3AJ21OACS2ZYywsAI
jcOEEfde8C2ehbRcQWIaR0nO7YZoVcJf1C1FJMqikRhXSVDWoLJuCZJKUZfw
wA4sZo7rKxldSGXqx0mY0fW6Ibsd+6tZ7in0SGRGSFLRBlOSXknBqJcdtAwz
J7OLNoLCuOuARetEHYLT4024bHCWuL7l9MPaoFcfPEAzB0BGJHYt1+MeFF5o
VHQlVY9di+wm2hQ1L7QyQ8IwfHcfFbwiEArU2R8gmNUfBtWUni/yQ0w3XIx6
ok0iyMWnL7drpEUOPSDyymCeTVuARYRf6094hU+KbLoOZE1JzmK3VksWmXWo
xD6idziLURH5Bou8j9w3Zo2DtnhZFnER1KLxWOKvdbXYFYHipSanyvpJn9CK
Cyq0R4MKhaRo+ZmU+rsQZaUyQGhxh0O4ATEq00WaHajrpkg0b3ocFUDAkJep
gzbynEsPjFV6pQUEcMFDewHKRJNEOFGYxag9+LZpiCZoZ7eRBpky/MrkVexU
cCQOOL+pPNDGuJHKsm5IIyBa0o9K0AHFEEkAQCjja23eRG8GyN6ZQigDLDYG
FpOMDcOwmyGZJYb8OouNI3TCs2K3kuj//F7zdeUEcu4wSKFZHN0qO4I6jiKF
A54osz/TJlv/ZdXYfutQrOwukNgfANtEFxIABpdx6ziTrFENCJCpDwrb5hf5
iAhKMYq0e7RGQuYLv45+gGcatIJv2SoHvCBC9wQqjqWDblas62JqBJWJN96u
H6u6Ks9wcK7JUIszbNygwYkds/PksPSSmB7Y6KcwPB4p8ogMRpZJh1L2mtDY
8pYrJsgtWTIjXZfVpuNd8dWyNnbZK7FX25oioBNigbTRYp4uo5ET86xUfqXZ
9FiaKpSvs99Er/kRK60L16gsRTYtVLdZtGH75i1apYXrcFUYNbSVEQ0kN2n5
ytJKXyBFhjEwSgZgds8kgb6whkBxKhLzDhwekIB5luRV2iCkpcZRq038InkR
6UdrS2lfkdlWGxbIBHEYwTNT5qeO8i/mEeDIiiOImgM/qF+Q77RoUyLCHMej
0aO3HQZT8qGPgiEOA3vCyA2gReFgYqsNaAeWA04HtHvnWETb0LQGlJiiIjH9
9rDBPViwOXkfogSTK0REjlE1S4AAlkXK90Ni4zAOx0kKzHKAvFfE5pJWogy5
+2LGZd1JFqR+/Er9SKpWG46qOjCa4Nn5nOHBATVkJQYZqTL6BujHmpO10Bbz
FI4mcwoBQ50AhDC8QSiMsQ6o7aWnoiLUbdDYwh2/A/t/5oNC3wji7dF67/zN
yduzwzcn67RyWNkUuLNmDDRvwJFIvBv9gtZWUBW9SYfRVCw0BNhRPG4NhsNp
i34BkMK0fPb2t+zzjviAm8GHaB3vxVtAu/WD4G9//duPgMLrgKd5msEX2x85
bJctrB+21CNd/EmrlSkeVXACzBkFv4tphOZ8mC0q+NogeMdZOANRGY5siK4/
IABwILBtFi9YWEOGBYJRU+/zgSCf8cwCUW2dWHYK2gDw24Mew62m93qlGkZq
/xgzoj1P52JXpsARx9As+qlSWOWCgayT3gHOozLbYoeo10DCstPi8CHF8Kri
UbPqxaiJZ3oJq2FixfpqPolnwJ2KO/aEe2RxMXcAmYXdAX0D+S8GCrjYYO1o
6eiVBuoUTEDMDqYgoU5ZMISJZsbboQFHxqFcZBmW/K5nCKkizIr5rKkt0VlE
xmegz7DhqdBu2i6FOSmG7dFL2Nuh9UYOm1DPabKUi9OAWQoaYv38syxEirBb
oxJ/OyFIlzRER32IC2XYGEQgY/M6tGprcSpL1wvUrnAzQTgizUw7fSQ+hPwS
Q7EEooEGD7LGHWuH8nx1clUO53F0b732Nm9vmJIPM6Wt4Djq5RESI6IB4sJT
0F2Gudrj4pMcNr9QURE3QJQIbDC0cU7A8jSfT28FMI+e2ebLmwT5isW0DpwZ
0lg4h/OlLuTTRAxD5IflMe1TyCU4ymMGEUutNqEpK+b5TAgOvbgVbKg1birC
ErNzyV3fpdIiQP805+rfYzQaobDAwRrKQ5c7ghuqF6j9oqRE/IKRHMd14wqN
u5cPss1UwDyOQ3oWqukDiNt5zTplQQoF2KOPl9BjWLIubUV5VBhTnbOs2WiV
x8BCMda7iZDeKvIFQCwTlJUAnkxHcj0Vaw5LZiupFQHhahSTcMqIxZSCQKyA
Sucks+QUuaRQqHRCJAW7eHvF9oymwSL3LQoxE9wVsbx8OBpxKkK544v0arS8
x2MKuMLtSByHtizI2HwTbGZmM4tapHI2IvJs7pAzFWCgMKuGYciqYDFRYeOc
R5FU8WWLyF/TR/6MqptXqF/4KwhvlfxpdcePJhjB2I/o1FkCx/MmdVOCcsZp
KbbXirCpv5IVK97A3E9EFm+EAAW4eE05HG48jgp9DSjiLtHnczdJp26Ygfcs
FnGisrJZP2QZyCzOKhHJim4giTcX4apFwlWgftWiGf45iBTGiqRiiVysf9Cj
4TsS4ihsBuO97xnzRTcx8jVJ7fEYRQlllOSbAG/Op6CeROk8t0MJZS1wz6Ko
hGFFBybpimdtG48izetpmoSQFBN8a6Jem2yTT3Km2E+bgshUoEKVPvM6nFFd
uzd6G3nsRSRQjAkuIuJLI5DcfXbM4ASJ3jAtmEokpNqkA468FE/ILIwzJh6V
4Jk4YUNy7jHOiffmnqPA4ZwAb/6P+ReEYX471olV9r8/tbz//uR9+JeSW1wU
mF+WjpwuHtny1tAsAZ7EQbCBB43nDEe86Z3DWdyaZzN/WvGPNZq1vNvV/sB3
rZXKE/KN/sO8q56RP+ilteC2Mv/tin+slbf9JxsQq/6x9ovrMYK1/RIcsW25
Q39cKp3U+qVb+mWtDMZfbGDhH4IzndpfYMhPtKMKRPHfgf6P86H0WR5bMkTR
8Q5RbK84RFv+OUO0rX9Lhyj9K7reR2uHaK/+78AmKGsfDoLPvGyJU+q+bFSs
Jg0g3QVG3LTCaTxOvmwge4yyxkfkcMj7LnstYTU58DYtYqnvFBfRtoLRFK0r
QG9v0KE4RkbFwfy5Nmooyi85KVWvwGfBKSjwJC2OSvn9xkmtzD0xP9pi0svB
f3krzDF9KNG6v8RUMpWWsDzL4OqabSlgKxyyQbscw5DNcdukIsjUZTWEhaHp
lF7UDqgJRdoYI6oWOh2eQVP3bds0siBxUI4x3Z8Ol0N04PfpkO0xp6PqWJTt
dPTtVbO0gxADuCOWzFsgtd0HjXmiR23wsHol0c0MZQ6lj+Zi/9M/YxgGxdqx
WIJPs0nyJpwFG1vvw61NCVCReWF1B+IPmYl85JtfEItCgzh2hw2aIxGMYGNf
0Ieal0mXiSTdTQZroM0yxMCrvMH1DL7Q5rQVh0GDTgOkyHhGZsGGKovgxF/n
AUhBIP/sNINdFln2VDg2xTdtCuyPtOxtzKtaM1q086ZPyQzHY3iKDblkURKl
BjQaHOvtFT3w9o1cTHWCNHYpfrxbWq7RIrXFmfctKXSIA7lanB5ZVuRmSeKu
aAD4tepuJLsaLsjaPcxOLu6O6xpx12jldBBuweDJ/KYv94yDE8jwiRQWnRXz
LFFGE5VUKesF1SAETI9uFm8ENqr3waen5wz2OmWIKgTg4CCA6KEYBMOivIzS
/BiqiZF4otLxWmQjJxIEpYV5a9tq8UNyrtG6JQYsCqZRMi4muRWITV+oYdSl
9g1HBBRGuZnfmARWfl3u+U0UqjB9d01BZ49M1oZkbL0fbtEa0C7Lf+93tmRz
V5aaYxwId0VrANpIC0bJ7mfFlqVx4ZHQtPNcYaN1h+gOnMhb1YSJMsozVW2y
gopXD0M/7cjPZpXiZhEROPTncZSjTM0RoXJUlC+BcWT5IsLsIw1uiKwT/Vr4
8psGZKYy2iDuQCdxU8DnXXhvBXfBmRj8fvVtDxZxM8NYkV6UxeFUJ92iCUsB
Yhf9OJm8cbLKG3tolXJ1wVCYZZVHun7aVXgh3W5KlXFynN10MeTsHOznPYED
Js8+pqpRC+FDZ7wYOGTD1fdYbMF6gGvDc4KXtPn2SlOfLJ16b/HUJ0FvQskO
1RWojBXvmw0+ogZccrrRlDh8r+mGyoRR/LbCKF0NeO2JS0afAOHcgP0/KV1W
64HO3gYRh/IjctOeBH8VofpJYDb2BP6erIfbW52tcGtnZ7C7/fTZ3hD+3+7T
nafdvWd729ud7W6tLru9v7W7M3z2LNwaPt3f2Yue7nUHO89Go2g/3NuOtvrr
TT2nJUTAXx8+ml8AEEC+0dOOy5ms95919sNOZwQEL9rZ3u8/HT17uj18FnWj
TudZf9CvXU23u9Pd6Ydbo+39cH9r1H26u9cd7WxtRVFnuDXcG9S+uDUa9nd3
nw22YACYd3t/ZzToRv2o2x0+3Xra2a598el+fysKn+5090ejUQdgtrMz3Nkd
PY32wtFgGHZqXwzDaHe0t/Nsd397a7C7v9d9urX/dDTY7e88e7oz2q5/8Vm4
D0sC6O4Oh3s72/11evJH+O/m2qZX5anwBaXySJQGBe0Crl0TgXNwp6IDTaNR
YTQg+D8koZJWdBMm8WzOrlogfSqzV7zKqDPYASikK1DEZJBEc1Dh4bJGXDqj
KMLBuyAco5HcToinbPSEIjspmA+9IBj2jMbUOBnOxWV/2ZMEy9m8iNwYLjRV
RmT81s4GkrMGaENj/Yojw6iyitKjrKwpFdgtvNFIVrjHit1P1oAiyYs4Q8u8
nYaFD7biBJ5o3aSwJQU4x1hvftFCLgmBOi6BRbfn83hqnAhKcGJ9hJ4nV9Zs
XtSCJi6F2XjXOUDt8aNeiUTyGbe75PTVvp/Zb1P9BBXQUHkhnRfwBuKRFZvA
bsZEtqKyDjhbGvdUjTUtJbnBqFPaYz9CbdyNxseQh72deTY1EgluB0sF0B/I
YylyAc3/WGmkJCiJmIQFnXQqH+U1ROR/akiUvhtK1CDVieKMUEExBn1b/L++
etHaN6siToYlpJCT6RwF0qnRFI7oASwMtRsV6EI8sbTefZ1jz8kmKNiVZSvz
9HZ7xwm4YgzjRBDgPw3nNFhSLjCZk2NwtNwuPhURzMn6G9pysMIlVoHIqXFQ
/kJttjS0Ck/mpGStDLDjsiGKii02mDVTiDAeFNAi8vUqtpoHGzoFQsduAKmw
a9XESQJQQBeKvUZeBUnenEz4pnqTr0mds25yieT4KQRZbxzxBwkghW6Sff8G
M/wtSkdxzjlnJtAydSKT/ES0CjlAJcdLfafEer1nfBOr/EQKX1XKg6SgSH6C
N4GthIbbpUIlwbfk3apmoaazEMRiImAceNRUAcHw+x0H8SGXKMoZLaJxWeUa
KFlbaCEFCHM8IvuaMV8lEK2Gjs4xutF+LMObIh5sXyZqI0VTgHEaNVDdXUv7
w7AgKSCpEOKwByffOlKJA5JuXFHI9o1KpnLYTYypr66MyYobcrCs8q6Vw0EF
tIwsAFqq6JIWlGpgQIwExyhtzr0PrXUrt7CJN6lOhLrkOWAtqFuWjojXz6Js
Ou0lHnGYiJqzhgILVJgZ4esc6okbppyCu7gK1QoaOnYd/8Fg/DnFI7Yo+LcR
mvoPT8JB9KdBP80arLKT2MDUORcOLSqbpmRoFTQKHQ3N5qhZeD9NQ9HITKjp
Oh/xWzridbFpuiQR8RVXRl/374tIsRhdZoJFhOffX530StmUnKqwgv004dcV
VfZyOW2zBIoi5c3UNwssZvNEqDa8Rs5qZpVVSm4IE05Aso6HJreX7ejVI3b0
qrIjl5WXtgSPb+qQAEsLd/Ef2fUnwcCfcpAwaN+LEdA2yfwKHMTlhMoO7go1
VyffXfkwbKXjwJfVaSwDb3vJqEfeUbXs19IWPmseOFnCiJK09btGdeRbF0jn
scSV12MkxP+yt4rYgbI7xbJzuQWsBGaWwkJUFiY5ledQVbJwRmD9Um9KWeUo
Z1n9sW3+2NnuECuTNemA0jCYxdHA1HdpqewIOzMM2R+Hh7EgR8h7df71ydnb
07MX5xyG76CeRhH/zboLjTk2VhyJ0UaPqvCA8d0+ZZvWwpHcRvcm6LZ0Z8xl
ogEsBmpRgOqcC3FvgxFns+p8e8ieiSgogXzh9XzY6uyb9U8Azm8Jk6PHwmQx
/amQi0ec/qPhtXhpqx6gKOLGoKwc8GI7QXCSNcix0BvHKOuU70V3rNCaXIgN
Z87VAYEEbnTszZCZGfn3kmpnsXeGCO/Fea8SRW5XGNAhzN7ii2XhnF0HnFiB
+h5S6NYL1pSA1L+8urqwubjg+WhKVRmUuhUWPgSmIlvhbRhPyREopNaRAwZ3
RYMjtzERn+Ivnd9T0AWLFpbPDm8aRkAuhceroVXZLYuab/pQSgQGtWYboP/g
M2parpvl0vpqu96u2fWn4QQr6Aa/BXiHc9YNguOr1xhNTcUxTeQx50jZ8Cgq
VkNjLeraOioWfShnWywB3vosf/eWS1EU9+ulyAei0V9H9ycSQaPF1A2KPuHz
pl10YBlccWR756kKP1ZTeIYHtOp9fSrfO+dwkUXsGKJ54QrnQiNDWc/LCEjb
opVsC/p0aCWPPiZrTW++uboKjs7Pzk6OrgAlBu+ilU8Izqe9Y0gVCV9Lzqji
bSQglmoRHYPyWTou7yqt0idsn8Xg7nu71km3i0Eynb1NYxQkyIhHnSXc4wgD
V4LLkMOxIzFhWnUHtAnmNsziEF1wpuaoqtgg5XnF60uxO/mcgp+VsSbHUh4v
D3svARoX11eCq8oOoa3rSGbHUUJ1Fiq2aEaWcYx1eF0aXkrHWpTXTuWO78Vq
46uRtyTrINiwCi9L3eVNVQYUZZjBhAszwCR95VWwNu5UW2NLtRN6XivAKVug
T8oCoQQuilVi4o4Mdljng6yZxcRUelBlSBRSwI0gj72UegB+zPZWcuGc0qlI
ZsVR2V1Rr/cMOEzuyufk0GEDn2z7tvnOTw0ebMArS1u2F6Xw7kqX3qMvKqhu
Cg0aTK9zuihgaH7nYvuwnPLil7zZuFzSwarVDEun1kI2LrkNJcdH/TtoJmGS
TNXCNSiGFhyaNXAjO7fjV3sAMCrZ7TVeMKF2DqAuFaBOSiBaiNUMH1CHFyk9
cZ3ua6GFxVhMBizp1Ww8U56vB4hFckfqzEtk2alWO2HFoBQMBRtVuxGMaJaM
eve4uL99wLiqYOv99pAjrtrtNnzY28Gv+n/7SFOa2mermwV9lptYsoeVphhs
6Ky0heG6rtRSPyQbvz63Dunt6iYuR8Vke7A71tJtl6YtxbNwBM1BcESZ0EMs
izyMvuy2tzqba65KdBD4JPO1N+H71uE4Ogj2d/e3ttYuWAA+WPuwRkEkNqZg
MExwEEzWh/vbw+HW/vbufnerGuOyIEPDDX8pR7kseLEcABNu7cJ6VUTLghfr
gl04pmXBi/XhLhjVsuDFRQEvT/cXvPjIkJdlQS8LXtzuVMJemnzsdN5vSaF7
As/twLF34dNFehE8kUckGfVtnFC0Uxce2d8DMDUV4kRvlcHySbC9Dz93MCgp
DWdvh8U01+NsZNjgCQtlmxI1Qi9TKs3OPjBsiAe6w2bwZO2jNx6nTJo84TgO
VSargZ6KNQqkobXBOStxCmKMizkFccUHcQoc1MspfhObIFCYR3AD5vXNhyyw
Ed2/mgBn+P5FfKgsBBhZqyQfV7ypm5KjFCmPDnAkfMc1UUAZmU3D+2A2z0BT
IffP9N4uuHmwMInBGGEfCHDFLFbwkzxg5HAxl2nazuNlpsxf4f5YnbOWudTV
1cUTbJ7S3doKzr/WnOmKmkH6vGtrR9gfqHXEvXEOgiRtYW+WaO0iC8c3IX0x
wEdKHKthI3UDiA4hWf+rQXwev+pdb528/+7v1/Hro1fT/s0b/O65nz6+uTrd
+Wbr1fHr68nVm5+uu6fJVtv/5DeXnfO72+583P32/uJ50v8muzy8vIpO3j17
d3zevauh+D8fD36KXya9V6Npb3jbic9+nnz7Xfj1y503Px+++6Z4438rPRsd
Pj+9eBX+cLP1Mjzc6ezmt9thNH/+bXK8/6p17X8rfno42Rt8G47y7R/u7l58
ffzi+jr/9mXv69bpxdfvX3/lf+vq3dnx1rPv7n86v/zp7dHLw/H5xatWb7h/
fvbNZfLq9lv/W8nbyXd/6Tw/e/Py79c/Xdx/f3eSX06OJ3//6fC4uxffhP63
8vOrfJzN0/7s+6/SbwbfXd+9OE6e3qTfXVyOjk/2W/63ztJvvnt69vSH79/c
zK6P3122jt4/S/tnX929+mY7ebNbE177/VFcvE+/+cvF33/qT59++3z+/Olh
Ohk+T384H/7Q3anZ1/SsM/3LaTTZv+18vfMue77/fvz17eX1/rvxi+wkeVuz
r072w/hs9yq+z5Obv19dnr/Y33s2/aYGkQ7ff79/fFQch19N8/5X05/625fp
D3UPv/n6fBo9vf4m+2ov6b2/ev3d3puf74qtNOu/vD38Oqo7nePvb2enh9EP
T7vD6OX7v29n6avj7765n7x/v3X3dViDdS+Pf7o+Of/69C4r3r0sJrOfT8Kk
9/zs+5c/jG/Ozv/ytOZMp0nnZP5svP1qv2YPo/jr3c5f7ib5+1etPH7+5rJF
nIDkgoaRQBoBJjk2ZulMfjKSB/9kxI6GJXU06K1OYwVxAQnOMnGBvAklcQH5
cq24QMYSIPF/ExovSvkit3CmjCP1BoZLp5j/JzEpVCofVwwJlz3ZsB3KtUj7
z3IMjxZzwasVnv6JnlbquJuAmfN8C6BGk2mJClbLoXhu8way4vWJweXCgeVp
qe+qfEIK9FSbCpbU0WFbTjGmeqe5Me82pTmV49m/E2OcsfuKQEY2z7KTfwHc
3CgCAl9Xr5WaLanSR5aJRfbg87RSeRu/PPpYc1E7eBlRFYXCXZVlATc9mh6s
+X96oWVbw+82ykxyX9m2xMMtbA3XViIgDyRm/BHWgnSxTxdPR/t5mHkO5j4q
dFcXKTsdSOGflLA02OEYrHPlZNTwJpnJtweqb0l2tcXlg5orm9J8JbAujVU3
r9hPwgfbT6zAEzym5EHaRtWOgjy3lBPpgkwlGtgEk0Kx3HIdVV1F7JiJ1J+X
ah3UtUWa3sL0O7/9XX2YmfaT3NUymE3q66+3n/1OiMSuPjiHc5g8B53aUIVH
U5WWterlcCKuvg8P3CAsaO8fT7UWIfbvjRK5RMKJXvutSECdJPNqmSTz0wMk
mVf/MySZ3wFOr47Pjgyh8ToEXSejcBoLiZYykZV9WIG3/uTvj7H8cy7iju88
YNFpMvz3OZDHSeWPF590yDZz90cw83/U8cvZ5+/iWc7S8jb3WotHEsgz4BgO
Xh5GR2DBhNpukBgVYccJYDa6nKIdSOcPyLBLUXAEGsc15T4SQ/nwqvkIr9y7
n53fx36IJjxsP6i3GF6nuReF0shRUfk93qWEFdkkm4YkNGkG6EXCLTalcjbX
2aWx3BTiVSR4U6SyjtVpEjCB6aYoLZo7h6Wr2pV07rtUfmRzRymV25hoeMvc
iLy6/AeldeMckxSzL+3u7J8qq/szqr5h7EqcuedJ8rbpoz8YRFnJltBYJ19a
miXUZURjsyDT01PRsL8ZeicRZRL56QgSqniONGojBmLq5fBOqh3CrLg118zW
DtxGb/RUqbvYTT+SwpRuYzL9vNNmThfjZ8GC4j50REyFVArZcGLAq2PqijvY
JYzyW9BEGmOnAQr2wklaTMqlkI8uHhZNJfVVYUrjLMT+MKeWMEl4cahkqoZ0
zQIIfPhAD7eth9v4cFs/rAq4lOvTUC/cmARSp++st2wTnyVTI3ff+SRsdXf3
Kr1LYYyXh/gLIBuWGYItY0lEakMSq15iAlsslOwUhPLAt0h9wYUSH1xQa7Ga
Wu0WZ7efEJvpwi7g+iYCU1btBOASrlhPv37gpk37QysLCxuVeEqhcYaWSae0
QpWadtLkUgM130Yr60sXipIYmJAFvELVkMMRuft5OiJeqKvGSOc+ZHKwDDlJ
rP5KgYFxQbVueMRKVTr5XVsQ7HJVVlE6BklgDbxCfwKrmj6R2WvpVGPqIFPf
XF0rmKsLf9SYWG7Kq2iFCQ6+S6lkUW73I0jgwqtWBQurnFej8Cp+7lKfI7sq
eDVSzbT6dIQ7U/uvPKJ1+DphWs1kbchfT90uor58J97uTJ7qdA/dT2XcxXuS
g31z+L2WoPQlrTaqMr0csXQBtrdLs1KpYwruJZhaLaik6HGpGQ0pwxI4T1QX
a12BtIlVnuOZt6iAgnwqzdGjwA745mYbaaYC3uWCzzAj4j4ArpihtwubWACy
DtM7pnGytxN1R2zCplsoLaq1sdd2M9m5DBgmsc8TXc7ZboSyrL2hHa9qlafE
Gj94VawGwbqAmMimHJuiCjfpblE3JMga6drqx1cNSVYz9tN5om+Gaz2Th/GW
vzAlxxb18fDUeaT+pHTAWvFUUj7X8Tdh9uh3LCVilfOB8LhUTtAVsTyVcxPn
IgsVDk+5CWcmKp2+kR7tqsRI2KfYsNDqaqTrnUpsN8I2QkSjruuWeMlMkeWQ
lnlTd1lWB6u5PfIKzGEgGxzoyLcUtlzpmqkxpH9vOjNz40W4lolPDLAbJ0dD
t554vlgAuCrPqovPkmKIi8LGIVyFVvp4Ulwx8QH0sZOKh8Xm48gut19pQyfn
/A9sMidlHsxRyN6YKjnd4ZjLSk0iMb+H3NeUu8cpLFKmTo3PIoNX0GO1JnUl
oPhb0Kmy7+qre2YCKzak0/4/aUqXP6YlXckkhcSPGYU9AlUqXLVNoaLqsnBr
O/itvddyRVSLny06UF8PnMOeVvUZA+E9ksrhNS34WIX8fRqlxTJaMj9q8Lrn
QkwavBefhvrkfwU+lRr7nZLpRt9aPUVsNXtBUJkGGdRdh+GGYkXjiFrDNYDb
SgqdMtChiIu3vA/K7ijGgkVSM02J/Mh8b9N4iHWzcZ/UuWeK6UGaylPOXQ60
LgN510ZqLo8kXkHMHR5FiLiUeTWMpvEt54s5rzLorBQlKnhsNVvkbgo/hdQ3
wzRIceZF4JKE0A56ZMltOgybGy1xL9zSiyXLj90ihW2PSNJRukGXPMLI7uKB
lpSmuZ9cGSG0W4pWWzk4t0D3AM6t8FrV0KSEBaRGe85VDk6Mo/7mu3xk6poo
UXLhRamxb9fcFG5FiHeEC4EVlZti0V0lhnDpNhsJ+HtHVFpwoZp0o1RdYgKJ
6J+VdVO8klmlssUV1EGN2TwzelMXEC/CeAzclaYud1CZggY8VYeDpWUsOcOu
PUWdrRJlYSFMxQvqylh8oTQ0nQtv6oNXzp6VwRMQjzMdfJ4znl1kKSiUN8Gx
tBtVwnGED+tIN4wv66UgV9PXPkHTr4XSheL4cX61pYuG20hXSWKc8apaqgmq
0EXntEgcf0ZWth6S+vLSiOkTnSlJltLFzE3KB/UlzqNWaWJL4CyleOdVWCi5
OizniN+rcgM0RwXkpj5UXW1z2uamZb/Asctir9308FTMCnZB3KM5XOKb0uxC
YNZFwOZjX7fFTIJ1HCYhXAocoAwi7o5Z6jdO2ataWqmVzpUryGo7Z0wNVp3k
Fu2ck5jXGY/i4boGuLicpKQegOZddG8XQaOGhfiuXahwnkhbUFKxVI9zVrO3
eCgrTc4eQnag3rPOmEw4hBWG1Jv2hgQUrccXIQpP+v6s/wV/WEcT6vxGh200
0AHut6XRbc4byvB3714OOjDln1cvtlC+5CP2HlsF1NI3lkSI3wLOnVXgXBlA
NRfAH6nZlBrhfyfAOv43ZqmP9uS2oGJZGXgxsyIWU9bpWPCkbrG6ay2XZ6SO
xla6sXOP9BXgLHOqclpqrYRjomDrvBl8GXxQsc9bBwHRfvn3RaAuAD/wn0Hn
IJgj1X0S4P7hAT42/NkNYRbCAIep6IJiiT1sCowxhB7qQJpdtoB84ANCuSxi
5WluGSsvkiFKiyYGssQ0Zj3YUNjW6m6qJl/GwiflQcsOY2NWD4PJ/CbEqxAO
MTG9aXchBsqj2/qp6uAL7nBkv0tzxrnpnYIXIU9HBRVnjJIx4BkVhzdiCiUZ
mf64SURB4AHWWyCNnRw0bHVGG0WMin5/Ph4rB5/qhU3m4/ccpa1rKpAQgaYF
ZPrlxapSGL2X59evj/FCT1PVLcLen4a6xt55guUrplQSL7oNufMt1spMkKzT
xoGpzmfiPSRgO2vBQaShLRuuqGhqZELmXV5qVYipkQTQo+r2a5bBSoILXV5f
3utz4OTSoFFyX3faW1uLc18XCQluOtETzgqgBEegqXBDG6cJICycpsmmJgSm
1IQn0u2dn291rccZy/GQTRfv1u62vOYSjSdBVCJAB0JGnmiiAR+BoGzB/9Su
SDIsMemSZqRVwRZ2MDHmY01ahB/8nuQIVwr1CqGNj7pKtPfsE/HATo157wGy
TWwTJVIMzi+uTs/PDl9TWLQox6PU34PvsPqtLZAT9fBOS8YzKYoxx6xVasTO
tm3tO+RzxCqvyLi4+oYlJ1NdZFUWgmtyDHQzQRQogJy852KDIBPrRZHN6RvR
EnzW71pThpVtWmdlkMa/sjOlzNcYs0Rp11VrH2LKcqKUbNO9Ux2WNCS0k9+L
OuEYXsQFwjTPUvyNcuy4Yh0LQMlIVdcvdbFN8mqyKEkHFkA1XliXM8aqUDhC
NKyBKrVt8bfEJbyzbcJNqzgj2RIEzGFuVppXjX7mx/Xctk1UDReWVeOBVkeq
s6aPhFHkEXbFULVNNcZ4BWm6buT94lAdClEA9hmTaq4kzDeH3/3t7VnwH1+i
hPrCwLaMLc4J6S1Pp6K/wXZvwvfUf0hGzPkOorLnuwu20WfhxKT5vIuiGV64
wTtd2YlneQxqBksvuj21EkIMwhjfpZbmeTVNmJ7TwcpRCktdEza0lOm/CmUd
SwJ3YYBOAnVVUEYJBpMsTVIQdDB6JRgB3olopLzKBQWuqQbo4mIkX5b0ZeZA
GWstSr1BcjWNQg1rrI9o42l1qRygFYMgmCGHSmzZS7URtqeehvUzW4e8dGJl
wNBcT/oKak8YF5kKVO0S7bVitVHZbFSABnlY1Y2TnokaP2pCyVm+JV41quC1
CTE/7JVyHFZqdF1FY3Zm06sieobUXz4yHYzNzbBNo7O8bJK0CqnrWUoxikgK
nLyqrglEt6Jj0JwOK8qDBvCvt7OwGEwaZZqoIkXwiLErEdG4BlFPxB78ukGH
3eBIlbDEmJyNmaByWMUI8E48b2odnngD2xcnvn1iIMOyV87tmdwkMvzECSUg
6KvTZDWKgNMxsdVO6FAS3dnI7jUP6aUT1dexrbv64D2XzhOzaVn8Ld+izOOl
1Tb1G4IWJE7jdDqMyne0hlCZfBu7mbT9Zj3dWLSFpjJ+E7XYsOjCpo63dMRB
x0ZsSicuEwzFJr6iu0GKaXgYiCYQ4TQvtywVcXZFvl2xDNHJnZ4dn3wX/PnL
YGOj+997O5tBK+jojgyN/24oIgq6KIAH1FMJVRcFvGSSsoaE9y5Pvrk+vTw5
FtcVYDQzgA3BGZ5K+hxcnhydv3lzAu9Wn4elbXd5aW17DqObExfLWYYYJ3GB
FpMx3RUJBeApKzKlKtGbR6jXFai1VwkuiHA+/Pycfc02Tn5Xz3hjOcKKBJhU
T2YdC/W8X1e2G9WWUdtwuLei/Cgyk/7RwKct1skyR0Y/4TLma/wBshjX4svJ
F4Dab7+rFEBVL1RlXQdUVoi5lUNlPfE9vIYNBFFT8ywifvt9AGiLK/gTIEbw
/wpeMWr8iXDFCC4kwMN+6NCZPjuTMTCtJasZJ7olgBmdbydqjzKWMxJLLJRs
SELVXRbOWmFG8UO6eCsPTgM3paEFNUuc57UbFqg7QWOU6YJ7kiv1Jban1aeR
28dRi5mO0AcXILpNp7eR5SQhmlniN3ZoG7Ha6bD6M5N+aWrawvJ0/AEO7RCW
ah1XCzvrxm+fl7/t4LdHzrebeoxVnsZvjuGbLfNazQP44QQ+dMyT7vf44QV8
6G6a7UgV3OoNRvbyVkFerr5Y0iUO173VW6LE2pfZusnqvtXSFo6FlZYNSeqe
Bd3jPsXb0YHdR8Vms3RpSwumVHle7wJpQRkqOWrXGWMS1pAFI0P4GHVViK8X
ECjApf6C/8UFQh2pa5p56Qg8moK9HtyX53I6ewey9BfiVkKUbJrEWVg5x36Q
h28ZfZD46UKbeZYcHf4Y9vN0Oqd9zhPpQOBeT0P+tQHAAQqgJ9AilD4pzNcS
8R0bkbE91wVRVClRmJm+fmI0tex2/ggJO9LAiutxTddVG4CPdWvZyrqUeA5K
Ump6TRxvj09fvHj7/PDq6CWKS/jNmetcca1h6ipLa7hyaA2LODp0khiFBBp7
4neYk+toAEUevpciMqqCjH6gathKM9eu5b18ngtuRZQhGchrBONq4EzJ8uEP
xHSjL62EEzu81pYurVN4pKkEpPtvCLYXJrLEK8xXPJtra4cU4LkgrrfisTOS
jZhU9XBaueFwy3gqetU4wSDyefIuQYdN5S3kOOuIIesHlIooCMSWZQl84qhZ
Hb9u4ZNlGFBA8sXKgeR0qqPodcg1VSU6EF6Ow6jbgSySp9bexDDYAIql88A3
jbMqn6RzdCwLkEJK+Lkvh48pLEJ4KiQSTqBG+gJwWhYTVm+stm85WkB5pcuv
6UM243DpQ6vmjHKTVH0BdNq8Wz7V8omziV5iCRQILCxsKjfnIMLENiqcf1ch
2FaU2AIUsMNvN70VJhS6chAuDIxuwGDDcg9awImlX/eCzcli7Ftl+6FVqhK7
MBOpi7UFMM08Zw4QzYyVRY3NoBuY1gwqTMOsgoN+Fb4TVCj2YFNnJPKGamOk
Vg+O0nPVheNXGF85tAz7HFj9NVZ35ZWkBoKFiQ7icA+TaUjkDY621u+5adIF
yvEvqsG4FQRDZEu7ZH8V4SrSMXfJ1OzCx4UeKUPU0j2AhRfptHCst1/Gcav6
vaXy1lwImpTkEks6MNq2PU79jNYV8hgXrEuF7aF0UrrJLyFhBLMu4nRupaP4
oxctZuvA1xATC77NFU+ihXVHJaq0aWUgL31PvbS5lBbXIU6ZKtcBeQldrg2q
16TaSYONpnnENjcayoozYxM33JlNXJoxBz6GrTeleoHXZ6Wvcw1qxvmC7X5B
HQsqa3wE37F6OJWOUK+asvVXDOY1VMrPZBadsXVdH8X4UK4x/RM4gDyX5t2T
VIVrEo9ZNNzvhO1I/9GrEijNxeLIzgUo5GfQLkeqcGeeNwj+cVyvY3E98aYZ
AfzBfE8DrZaSUN/RB8s63ATaftcv8hrzQ01EiC/fYPMfD/WFsgYLYv5QoUro
tnsslQBI0WN4S4ujYpvcouLhfjJlkPtChd+6Gq3yWPtNOCUC+HlwCERUoGj0
SSQgB49dnDbafYG2wpIBCulE1QCljE9fGD6xCkL7kZJAIkBw915npP59I28X
kPd8TqSC84TFrPU4UfkzTgb9psw33WoEFtek/rA6ChY4ABWeqVdbKdDLJuJh
/k4572uY9rKIBeOLxCAgS1LUL6pYLYIZ1og56ZkMejYrmM7HDraGVftRU4/g
cHLHM1+bCLusLlFNqFVpCcYnjylN3HxtLupuaNrKIVOVjnwmVqBsnbPUHvYs
4WKobE2MbbatItEURGJ3BK+DWVKOY6sALCSH0wpAc8IzAEfpFLvtrV2MBaal
uLjlLOZROnQ1g73cM9Lu4VFNklHXsyblx/BkxPW3gJDrZR3MNs5SIJJllrBq
SOgB3tJVX5f8Y6soS/mJFWqzUDWJUfVstAJmbpBWP61LFesyKkXdFt1bU6mj
oujn1eS3qgBTlYoWwD9+iAqg4ns8QRYr8BA3NdmufbWU6VimA4y3jwpPoaNV
tWQrdSEv3W3CEzvMmVIamHiIsY/wvDWfreqnqdXhvTYSw14XaNcPU9FI4S0h
gHBFbQNBfVqbEw04fuXMceG3v9dYCgETDZv+8GEwHDIfthNcSdrA1CfSqeK6
5KcFRMTFGofaWaVKyMblSimeq+7Ln+KmD1Qv50tuJbfmrgC+/uvngXnsx0oS
g965ylko79hD+Wp7OHz4oO03AkzMViEeppJe/ACwxA9PIrTPQcOFsinf0tTd
WW6sJy2sDocm3L2pBmN4UNvRV9RzM5XnzZAtFxLyNOqq61On6m2rPnW7S/vU
aX5bavUTWVh1EPyVr/5kfaszCnc7g0G73d7Z7zwDofkJkPt46C4veGKef4rP
bcHz3e42yNELnv/RkzXjYIgnUcbKYX8oTtS3IjO5IAvkcMvC9mnlcK+Bb3U5
XNdCbH4qBspzU5lrKRm6ow1HbNWiPL5VCwbUuvFNdLMd0Fhx8Z1dv7HFOl1/
mijYWZWI1tk1K8ZMkqB+nodTtktgV+Sy8gpcoKU2V5cQ8WBxY1MMjrgxDAIr
BdBQyIETTW0ePHNkdKt3zTXQcvi0AY82g97pDyc6uBP/0JEMlQwW+lWCSWp8
o0ZVoCIZFrNaHDdpgqwBijAnrdIt4gNHeV06Bell348GIWpZan3WEypiuqvg
CBKn61amGrw0pfhUpPQMf1V9uJTEdP2YXJEmu7g59cUAqWrhqEbOPwKDvP1B
OALUykKiRCYdEeWUXhmxTi4bkxvPVbxrB5DfiTVTHFVlFNKgMGVNwO4p0uSq
VfjbW/ptfUnhA4xxV3qG1oiv9K6VJkYzrOtMgnVfhlVtrc1gXcL7Pfodqfuf
quimZRART4pgTRmrvlCVqu5Cf/FEq95pXdEc/MnKoLJhJyf6iYBHsWb/HNDl
iyFXyZR7JNRcRTk3+EKTCQB8+jNmZ3jV54LCmuoV6J0qEa23yYxEev0XMcrQ
5a8xyigX5CKbjHpfqVMpchNNI6oWmvLzZlzLEuMcr0WeDPugwumM/XZioqlJ
DfwjHk8KhrSE/VIBA4YPabeVxcRLbDRi4y6/11y8aG2/BjbCNwBIOnIij7fC
U+0txqzhW2ABUSllkPC3VLiVCbEz/SLoM9P1cicrV3ZhdqZFwrzTlqao8K+H
z1lhcbXWLe09wSqkvxezl2XFuiLCI0G7KAStaMnyCvOOJetXGLJqQwgearGy
bEh1ubtBf17osnQ1SlDuFCZ7iL3qcVM+0ExVi2M++xUu5Ffar+oI6EPtVx7C
X1P/x2PCwm+VhFI1YMGvhhLgz8KhD8xLTRYHrG/MayXTmBmqxjRGp7vANFaC
2CqmMTmnR5jGqrUA/TWJWS9EjXG7qgvpM32ACe1RFrNa5MVV/Kvb0gyGa1va
X1Xpqr+6ZrWt0V64xKxWMa3t9wfRQtMa/vux6c44GI46gxDe3t3bHq44Yz/a
6YR78E64tft0+YxrzsSlHe/sDIedLoz19Gl/sOL83e3OaDTC+bsP23HtUipQ
CZ/t7+EMo9Ggs+KqRlEn7PbhHbjtWytDZanJ0yYmy0yeq931BfSGe+ngtW/N
UErPkkoPHYdJ+8MQKeg1GIUDjJ6fUyEtq34VPtVjznelSuBc8GSuyfC0ddzu
4x1LklbRLbJxKy9mZCP8zBRFeuMU0L2uOrqsrG2V6eEULvXW7XmwHwm7pKRU
i7Rk4PVYoe1sb/PtUoOp11v4gPBYFMjsOgSSDg0nMyhUvaiyKscZRrmKP1Br
7UfVzALfpprqxUocPltjST+uCSTSIDcCqZB83zyhyYNSoUV5ERZzXaLhgXFS
WL+DCkypzlMaAXQBOdOrqFzdlJJjH1U78TMLswF9rEigKuZ6EcKXsLeaI8RU
q/agcmU3NUXbPfZHn1usxMN1ndYBiJQ+wVExeaObS4Skfrs+jI8j973lMeUG
1EUh2DGttZNYeS546llkWcaTdHU7sbECrWQcVmEeUipV7AS0EpIE71TssnlF
BR7lVs3heVLEU0tPr9F1nakpFtA2CAAYS5lCyyBadx68GXqU8uBpLCcYUVWK
XjVReEk05EO0Y1JZyp1zH22l6HF2gA4ZUQzTpmD+CFFlz3s4RStRF8u/6aEu
Pg6yJB3401AXx8IvJVlO2ABmtrraglt0RwyLfyh6iOFVWQ/1Jkwbihqj6683
sVaC9j0ls2trWi81pNZEt9XYGlcP1qoOt6z0sB59qUVspbFH4TSPePCdTdsP
zv4GNtJK2RdNI381WmBB+2w4RXcE1aiLNHNaJTEMORSrtgvFG1/6hLG11GR6
OTYfvEksvqJdOuiVDTUWQVD1Xle8ZyZj69F3zQ5M18KWh7hoO4Md9b8wiacS
MKEqgS7vG9I0K7VKUUrTzoG0djsU1/O2ReTsumy6noddReCBnIcMqeLqeS1e
/etmadBN15GuMqiulaPfTp8XqbzG9+3jsQvqCi4puuVlmq8fWRZU7ek/HrGl
iEuQ2ULE9afZYp1owGLVazXlo4IIHCTbsXw7yAOwsyzQ6fsae1idU/Cf6Y57
/Y9wx5UccasFHS/c0OOlVVtQrVVHDZ/LqzEbdhCTDR0DiKYpjWqYQv/efc02
rbtuOg9QTBDS0k3VV5f6NOKydPRDoUtxqzh3mYPIXcrX4/L9hbujdom/Ustg
41OVzjp4Vyfh2Fi3iuLpyDjI4b0Evr71Q5HN5fVdN+FWJbNXHEc1pvZBFGPk
SR2NMcXTeMpm6VAxdQYTSuqi1nVAHt0MZdirZ/WaLtOJLsksLbupavAJizU9
OI7Ryl6nge+oToipCidSgu7mpbZmVcLTpVzduk25w9dweM7R5zJwSvPPpLtB
Np8VlqdE5fSreV2J8BNKg/8oUdAJCqvP1TdxRBfeRHxd6I6tnZJvxeS0knmp
u/pSDiax5iO0uhxKOxi3ICTNbYoJ3pqKRhd6Y+Wqh3VvbFzYpQ6tqmIk3pDF
GqE2ohTEx8kxwtLEwqP1I1naBkmhbP681/1QUqqfRQXYYrj9eOmp2JxCN2qF
UQpRWz3+kWSeXbRYPSwSkuVEudhOCYbft+4erCZ5PUx/D1aRfX6VDh8s53IP
G9/mUTz+t1ZD+n6cSLEvk+jNE29i+T1eXVNG2dRHTzq3W6qqRhYz9jirwiHG
aVQaPteUWpyijDOcq4zIWGrwh1PCrjxytFepHGpd/CU3vmkWb4fU5BOO5kr7
KEipQlosTOKaLSrm2A5KbRJ9S7mQQ+CWEcj4eRg/2yxzeinVK8wei4nW+ySw
tc6haocMj1legAU5cbRRGLOpjaeWOFkpjO40Q5TytHYPmXqp4UEFbzal0J+m
maruoScLISwZGFzgGD7z/MF8hqp9PJ4n6CoGpVLHucVtPh0r+5WLXUD3fzsL
ENG+f5YRqHf9/O0SQ5DO+cBHnYwQ+EKyQnBs9Wc182M1E0lehFwckvg88UBH
crexg2Ov45ubaBhz5W0WIb6j9I/XS9I/aCPOIw/I+iD7EQ/xb2YXs7f2icxj
PNhvt9uSfYynezQA/glmsn87S5llOnn9W4SsP8gIt5rX2Ik6OFgzYVktDzGx
Xe0VlqbxHkFYh+h2Ib+abWh74CcwLv0mvuK2F0qKr5GcSwVTV9/pIiNhKe3n
Vxo/bbPnv7kZ859kyazhjuU7/JsZNGu58yOMmoEuVfGHXdOxcfy+DZPBpV3U
W0UszYtJmsV/5y972DM10/W7nWrfa2vHJpnPqQ8uwSsmCKpZKZfEIWPVQk2C
GeUkVKc9O5UysQIprZmt2y2NI0Dmn4V4uJ5i4qaTrnqcEh5G84QvqmpIhgE1
WOvfDnI3UWGOL4hLUUmP9cSlro2zEHs9nlp7eYnzHU7HAPFictNQJ3IPGgs9
3LYebuPDbf0wFtO9MjaGAeUu5qb3NRoZ50Wu8oLyQTozzaetJtsg0NVl2HsL
Gzghu/6MoYcV//EXSF+0MCRXf1P06gFLtCwSjDmfIqWrJjyY93COFh9EH+rT
UntTPC0cK48yY+MV29eB4wtDEzSL7c2s99jSrHJCsEsj3VnVqDHkYJdSpwCe
rNpv9mriNO67A6H6AQ37lJR1E2GbvjinHmNqy85uaZgIdzlgIoalXrnmq6Ep
dmdqOLd5Fjn2bUz+hUsOl3IwjSnJV2jAE77H5QrLPWHPu+19BAw1D9/C5uEE
DRjmsmeGgPeylEKFFozzrDxOplv5sRymGnWrJiCAKTfzRFlPiSmhlBwmxG2b
FlJUWj0IApEegT19EVSYeIlQsYa1dEiFVCBN3MyLObUmcuvqlTfkbodjkTXT
zGcx0CWTSoeVvelQhnwqziLQgVHcRab4L5UNLPMIhJd/aZQMn90Ti2MrCJCH
DLM/AL4FdVZ0DJD62yAc4/UqdPtxbM5LqtPzaETGZmVhQefCg7kaNeUBbIRR
+tMYaLtUqF56EFoAIcQmknUPVJqzvSaUUIWIMMWe8feVIhQMJBtEYmLXHeKs
vHu9OFtfkAVaS4LLLh0cAUUZ9UqnY7AOxbGM+i6yFQkm17NwCOvV6x6y/GP8
X5krx/hWtXX/Djgtcmdn7+NH+viss/MU7YU0e3DeOzq/PAEZBYaLKXaVe9Cr
ZMptIM5wbbN5kqi9u/j9DmAcveeWoYQiKUjpwcnxy/MjHuTZbnefgu5LRnl3
GE1vtPPNBRRVGxqocN6yFNK0gShlLgeTCKizHeTo1p4UGU1KK6B6KHiWpZgu
KNp3qus3TCJV01Kd990EnpTI8so5EyO6pxPFowyDaYq55zIajgTzSO/nDJWE
mLCQTRau36l0oAMgB/gnaCO0kmye81U1O3I5kbfeCqwPpFIziQGOV8rjYp01
MyCyYr6vVMvwbNFxgROpq90US4wSEmS5TxB7nAtByq1QtpaLTQ8hFdiSSXzE
qit92E/nhcUo6ogXJ2lySV2WDbXkqPi1kAFXO/aOqhqwyXgleROmOzqBywGg
w5Q4mujQBSHSElfzqDDTKvf5DJemF0o/R7fA2mEoPsYrLjartBe7SNhHkc0s
bmrR9eodTjOPsmJpocv6FhlVQ1zf/OiA8oxRmWf0QgdjtUrwknr+pVpmCzsU
WOKwyt8tSuux3aZH6eFFcA76KKiBwfmMfRC6nriCyKYrixELpS7x9KI+Hd/N
nMEr5pS32x055ad7Ox2V7lTO8ielSzsvp/dGprIiECT+nB2Ppp8QW0nUFaTt
6R+xuk7JIlEhP8u0jcWFBn7bCqmWKXFB3ZgFbQl8+EV18Be47uwmRPYlQEno
Hotxi9oTvQe6pjChnNZIX9WU43PyKeE4AOHC4actufdrYFZR+yycDS0eoGPq
xcJhY6W/8Qs3INAGEaQUThKk/7WypUzPe4NiAqpR1NKUrzJmlGbhHWtXKd77
nK0omGthTDu3qSKx2BkV5Hx9pSkCx1hjnSLfDqUj1f37AE0bJIEjk8wlEozD
FRYVFRUBTH0fq7p3wwqx4+/VZTD1tBUNs3mA1uaYTkUUj4WtDBbFNRBis8g4
bNcMy1VdfARup911CZzV8y+yWgQ1DfmE91EYg+MZxeO5uBH7ETr7Wa5MM2Uy
ZwHM2XdBG/IusyTgWxaEOxb+2M+lpEdurwIyjhKO4EJkcR/tYo1Be3YTvm9U
c8vjqBi1YIVRyxqhpd/Myfkvnq7EDWFCn1kjAZnhSy7y743oSGRrjJCXqjXQ
Fe8KtU9pMYe1vbigC7zDy5WyROg6CWd5ZDRSDD/EC4b0qnK2dK4qY1Od0KL0
pBLOSCYSNdO0CqlyLT2lizja4KqmUyONDPVZIUXesEC0aZSVGikFSUER31DT
5HCajjm8kJCLO6eoM6ZErzaHKw1TuitpmfgU6R1AJa9ORG0HdR+yf4CoI5aK
KRVBsKJWXJeCgdzUqD8PZOXVpPMHFRBAwfbQWw1qNYGB8MVwRSfWCS+0sTBi
77KKbyod6Y6NVLfU9UHo1u3LhWM0OGYRR5xQ8FvG2iqVU9SxsFXpyrsqrYJJ
5Vd7UVRVSGXhsy5ke+FqO/CKT4ZcvdRHW/G7lEM07EGE0/qGwYssfBigl5Sx
arUusNSbHJk0BrAiBaZ6cejnuWV6L42+7UU1Wa10mehqmcJSyjd0NykF6rSZ
2nD9ai3IhXn2RTUxXm9wGoXY3kuUVGyRVw53LFfH87jW7EpMAP+eBoFn+1qZ
JRtiXmYZTvqneNSm9xKf7mWbTSAi2TgiAoHlp8W8AoQbP4+EOFsGiZs4z3V8
jerygz+g8GThhyfaZ6p6MTIBm2eqlr/Lne3qZ5Za5ELVtxkN0dwVJom2kUav
6tWwia2lAu4YFC00UqgqNrk2CWtFcBrfxJIVfINtsokiA29R1kgjrzjmrXkS
3pF1YlQrWzLumFjgTBR/VL9UGSuSVCNqxt50zkRCZbGgHNH4PJ0Kqa/iT9UA
5RmJIAUUEB+Y3mvH9Eo1QVwJLtSqihX5DoIZfLzn6gIvVbGUWnMHYjJ9JO9i
ZOwfqs5Ki2DYYj/mx6pxc6mG4ZM+yOYPIJ+j/IKlK3XVaodwlOlhaBedrS1r
Vy72V56c+/Fc9oz3AQ+XiSZbo3gp1lxOP3tZN1M+a4n20jl5i6ZBM580IYfb
mQ7d0gqWe9UW5BTKorUsn0fDMk216OZlz2wCH5lJVFuRKheXA1PimlppdjuY
mWIF1t69sTbukDleWUWPy3XIMR9Fj1t5Lzj69kr8OQsWFUiQtfu64vPAzdKE
S0sEjXmi3TcNbvBlB5g5wRrc/kslN5l6yWSBMOFyGK64sfU+3NoUXUHVKyhS
bvlWpLPWFLB46ptdB/6d905ABfgJnYBk+FWhYACAL1hs9L8ceeo0NzDiLixQ
Y2lw3JVpBLfiMAjvBtzjeEbuzoYVFdgSXVzCbggIwG1CkZEQpaKbfjrUZnv7
VLQJgRzZ94zUZXVAi6mI3UhkeAimNXkrzDleISbj+gD5hTTXy+nwqEQWKhqg
fCVIXGWRRTjWwdUknM05HmusQgkR2dSTGmBxkpin7FBNPDE9Lp8RPsVh2LnG
GH1tUcpFWVirxtMoGRcTczQOoLhml14ARa/h8CXfS80xyEGdJoseWnJWzdL2
uVOg2WKg+1/ScQIzzwuHTsEpoB+OAGVNmiobazt4QQbBvEB5pzydTALjd/aC
DRzk7Qn7aTF6vC+OCTwyvHMD5dml6d724AI40PDQFyP3hMGr3vmZun6kmODh
Kc/tYBrGqBvgnLHeMbwEc5Nr7+lu55moZg+nU5r+v/q2x+vAanvhVDkviG+q
aXZVmd645EvCl6/NzQ64IOYKc54snXOvfs6ToDehqOTq1PjGkzRz32hM6LcG
8Do+3MQGmC6grsiYj/4cJpqlKR7m8KNi0qnypLLKUXQk1IXMvO5hWd1/dcro
FTPSCSmccpeIi5KNp1PtlSuyADNc9bA03ijKQ465bcC7JL2bRsOxcpB16EeR
PBW9Y8uWBMkMlY+8mGTpfFzeCQVxcUhlKzhcZiKupNo58+uUUfgGBNOYNHGl
1dkstHQUOr/U1/fA3ZRqLD9s0hU0dIHSrZasvqaspiemrC5ELFA3pdRM9P1s
nSlASaTs6AXn3gOzRiSXNxAn3eplaJu+SYshds8DzEJ2P/XDPNJVEukhcfwB
2nCub4f6IrC9z0E1eUnvhLrERu9j2Ym9Nokm1Q0iTDASaQtsV5N1dJaGJZHZ
xbFB6xt22bOiPKSUny2cLpKwI2VNd2+2q8ZJhAuoSiO0EOiJxQarLjXZGptw
/8nAGqOdBGQRlEp0I09JBAUilcJfpHkqM7evUbzahbUDviNoMvBshQ4MIHAZ
abtHzaadUu5cDYtWw9Q0vplRLVBK3wo2hnE+QWm62JQgtaoHwgYYdakv9VY3
KPIFN4hHYwM6soxLGzarRFNGPMZMoQ72fWd9Es98Sv2Y5GJITw8cfiLSdI4q
LXrQhecr0UllEgCyqTu4gZMD0883xZlID/xUeuAVPVBpBDWJxxM2x7nzGfVE
UzsHs0qeXgtMGhYAlsrd6Gy1t0uBBm76A15kCukmeYKVMxV8Y4HPtyhEjSmu
OiQcJuRRwTku81PoVLKnKPsm21XUrHH+rlk2o1WYJxn76hCHVoxQYYNMWLse
JUcx3muAcNSADoisyMUrUSAfKbNjSZeQJjRiNK10cG19wGbRddspJt1mFVZd
kZKd0hcWtKgyuxgMUl1KQxPz+QxXXqhrqKGkDLr++5Mn3U91h1ZEaqUtwNIE
FXENYe6xWXfJYsybJttTZm2ZYNplZ39urNU66KPrsWzoKWhONQtQIYrBRH0p
TuY6BtYzpnIJa8s9+a30yRrUxEi63HHIuehcNUhVT+Zvb4tJLRspzcBP48gr
kzJ45fNPQ8+MYd+qVtvkCdxUMi1myO7W1p7fB7dxVvC3Xu1+AUKJWdp2udot
EqoH6BxD5QzKnafq947XW7O7X8fkDH1Xzgoh7xV6ForvQgnhPJW5l6M52nEo
Qg0j39gYe2kcKq8xrPDCVOFGAy2KtxJb53gPUegqx+Tpto2hlUBuVfXmeGuW
0CnhR0S72mYhlTYVNcWhnbZTdmSg5oB2Uq9q1r56URcH3eIwCVtiOmkV97NI
9UaphCiyYFqQ54z7ZObzm5sQoz2ltaWGDdsvyHLGeHhDNmOXNUpHNImiz3nH
76J7pTMhjexTuwEJtGZwYTixIDcaGGdhnGmUtHLNYg5hUo/qX9aBj1B0KZls
MJCZ27TB9n4JMBsocP79wsv6GiaVj1cAo6D07xd4V/WXtd8NtvRHzo32/MN3
VUKo825ntXfZze2uOejqj2foH4HfK2VV8V0K1ijtN9jWH6+yOV24F5jW6M6L
nR0IFVqIU6Q2Eohz3S6GMlut88v1KdXfVoNBjUBaOmBWapRxH9v6F7nE/Smn
hcV4Oz98RnFchNIPuN9SoF8H4krEuKAoh4bFZhpVBAe9YWScjsvxYxIdueh2
oqk2zqPWLEsBoDctCTLm22r6C+VG86adxcN1sVLfcfM0ogJzkDJuggseKjim
oSRBbl3IQIveX7djK3hEvWbW+38J/kJX9BcYJh9kMUezVTFwS9DlNOHSMyZ4
iK84P9UpPSUBXxZBxae68tQ5xzj3qYSKoDiPZuMeIEQLqGqrevyChQ/AGC/G
2VkPlktWO/tqXLYfmVbqZIdaz1WcgDSjtFY1WOAOZvnhHx7gzQkWIj0Y4+X+
9rMu2mV1gBI3NwGIo/TbdM2cz3RwDb75tLvrf/NV+U2KvfPOYcU7swHVvLUH
i4W36NJwuJfJDVWiSTlDtGSktGFHTmO8bOLYVW2QLllNCKcOe+ZjOxTx2c52
I17mjwYToUVS4jmahLMd3LDNSpCjJ/fHTVBRsVssJfw8J4F1FE9hCTigYwZz
0xuYRBX3xhlSCRwSJotdvZPWbN4HcrRpkbYKCeSMCY7YCgutAFZhYmoolZOd
9Jj3LLWkVv5F1K4FfpPT4FnE9yXm2Vk/IA2kd8mSoll0PHauCvonHACWMjWt
c2ZLgj/NxyapThb3x2oJd8dIq6OraWX4M8YUit+7JgZOKZgZqXNNDppGcr84
0nxBPnBT9hjVxC1mkWP2hJX27yUhGim5yf6rgNOKWc9VLGr/3m4nR9G84UgX
K7k8QT9GRF0VsGszmzDDaSH6ZekIxGYuJqSa7E3PoaorFr2nsOxbRvBw2KLt
pTNNSEhcr88vYxsSFjNp1ixPqQoqpppJBLIaDoS0opIFBGSejTNgFWzvx/NF
PtyvHLCKx3bxASMtMd4aDbe2RxKTCSS6WGUO0RXn+PUkns35gnu3oRwrfamG
yY4FW83k659F8AQwq/lwLs0eQ+OHECusyZ0zuAMySDrPBtwkKZ/FRcR5C1qh
dPyw2JDs3oQmrrIMkI9mM2cZbCbWR7t0LSW9mf3ReYH6LIk2zGl6QFksuFFc
yw3aTyjmwmt9qFpJPNQ1ixQspBLWojD6ARlRxxkoaxT3lOOi+vF4rMjpnZtx
Vgr30bWV4GWKa4rY7oYm0JlJM1mm6pIDMCYsj0d26J+boVLvkXLik9sizPPe
+mTKmaaxmC7DoggH76StewICBOe0BOFopKymOqxfFl/auHOJ7IyrSTSdSTgi
Mzj3hDUHl3g1GCLDHAwCisRrlA5c2WGA+iDy0ULJdl1yginZxU5WlE5zS2XR
Uvggc9lS3iMFivpuWK5K4FjCq6tEsZlWIlpT+6hVZLeT3eYJ87fCTFVwnq6c
K0LKarH5m1KqA3hpJlnPdDro6nHnRTxJKMocia/GmUAHj2kY0MKSiLoMiksC
q7xw+2VZpkjoGI5Hrmq7Jmuc1UdXVgIrS46I8DaNhwTzVSMr2Q5UB+5HBFnO
0ulUnY1S3yngRlXrckrG1KNR085EsoUBf+B0T1VboQOHcxYGng8mERJytiXg
4hQvllRbLlOq1C085gWhnrQo2nARvuP6N8yRKIpWjMSM2VoQQGxBSeIW5Kyw
H0+pGIK6ieEwnVkJRhYeM88Uvk5MX+oTRkmUjQE0EhWBHmqSdWGg+EaUuHxT
tbzi+FZ47Sy6c+NROWxScTTxNHj9U+QTIzcwRvncsqzXj5h16XAWHS87JZKK
UX25xa9DD5c0flARgXgtnOMu2XhYSMW8udPe6gQb14mRxDc9vOSypyk+S1Di
frLNNlROU5kd7X6+zv7L1umm1lUk3oQd3oEOjI45JFSCF6zgVUcIURFXsmHl
qbIG2biPMMv1MFdFRhYsEimskSV4dExTS7jCkq4koyQ7q7JhnPwkAjjej/ES
COsiZLB5axCVBFFZGPOxIpc6BYhjqM/LaeAPw2io0uvlx3wWDiLVZXNKWW35
/EZROul9yO4TSTUVIBrk1C2vFgEJYGxRRacaa/5O0gUwc8O9DqnWnI3BRJIB
tZijorVXxlWTPGttx60bvWIK+6kDEaqoUgmF8gAGkY9NbCBt3pAUYw0jeOwJ
QCUfLpIMB2JpAgJRqSuiDIUPm1RTNOSTi4hlI7Kxe6CN1EFimNA8Tyk4DA0z
H1G7v8ynQBvJ23CFjp9v42QIYqwmMmtrhzaJESK1Ao3i4HJ2WVWBYOrDDWwX
WZV04L0UT6pcIvTbqEvP9F+ZHBndHb+moDu/xriMl0aXUKmEm6rIFSbdOoHJ
skpUt9tEoQTpPsXAIeWfqKgKVSZK75C8TtoECfLxVCLYaAj3dioSxzCXUEKs
cARoN8AKeCVJhgJ8UVp2oiliFegv8aZGjjGcnaP3MJ7sNh5izOzCzErMhqHU
p3RUJ4cI0OVC6rgHljGxuGpB3rxh1EpHI6d+klrUKGPPsunooXL5OGxZHf+t
QWDyXN4RAjNyX7AMicNdo94dYwGuN0r3FsnVX18D/g+pqKSX3FjvfKScxgeE
ijd1koQjl+rAMyXB2zyb41QJ/KoYZqlsID/heAO5BAaZULwz4qVhwzMZB1Vl
qyIcj1mcmmujixNc7s+xIEeMlTagsgUpnM90caBML/8cVrQ7ywiJCQvCF0hY
zI0xTAkoTjK0YJoqNsTVDa1IJNRGF2SLVBJXrGq/SFydd2lsK7OdFn1kmpGU
Umyes4+hyOamDnCQkWD9APTRmhAttSSWEEt064dY/dYT0bl0oTDFGtg0yIqW
Ln5qtR6InFIYZdanYxQ0swnSW4q4dnDY1X4xqTCJpjaNVstTNWrUpkhyR9OH
h32KP1+qVer8dZYJrnQckCW4aVObZzSK7MUKAboZ2jg1dHauaYacOIIOGRIa
FFAJmxn6Qgijz6EZUKJAOs7CGYzMgoJTO6YagyFbqNYpUzuhaMW71JxRSsah
/IDKS4pxjoPetc1wxIFMluuySmU28k3fqpp2iB+r9zKaWImx1pyU6VI610N2
TVHoPTujVcdqeNOwVG70E7057KmiCTOaFBVgFFXBnQELmaa5j+FjML+IJ2FR
BraqOBFZCDSsEbX0QBJ179xHAUI0XDiYicBSBGxB4KIpu60lYswL0vTJCvYH
xD2yYwuDFzHZwcvRcgs3qt53F3SXpeX4ztcUgkTx+B4sp1RfE68kJNTp0kIB
S7pvjz1blZbrLdjVaNJxggIQcyJJlLDN1Towzcr+0/opWyPNeFY8tU/MYRnj
Cm6kk6FqeBKzOnTYVsWKu1RyVls/3RUgUojjSSeztuIEDrOV8e8fdRQF85mk
NLxtSxOjV24cupGdcQnLLYV4V5P6K2qFKRAsPTVEzDBLqJ4G6lDEGsnDaEoc
yYF7VF+5UEo3tZxeVAYCoNM64t+0SmhFmdKl57g1zChCYYHtTXCpw6QQpzjf
dczRkGB1W82ytBtd0KOGh5Yiqa1BOGBP2WLwR8zT4gIvq21iA9fvhLVaw1va
H45rWLDmZYQiN7rKO/wkar4RmJSCIeqhuSoPWy1lbm3gmtF2hsEbJLMXFn0x
XW3C4OVh7+Xb07OL66t6EsZPV4Qsa9G2n7Z8XQYkMQHoXkY6o88lqhYxmKz7
lmE/UCfymdW0g1OV+6MiRQ2mM9GosQEQqylilQiXkWnIntyNNK4pOlFJKdTh
N7oGhH7TImclMvZingxDqnEsrEHXep+Esxk537iTDr5rnWKlprgLP3L8IDpx
o8Sc2ySa4GU/fsX5olvNhMjBblsDFFsT31jjx5WcG6JZTDBVJFmZcjqGJSZ5
nGwpYWN1nE1EFKCHg0eBCZUhi/EgvD4FuDCyPJ5KNeswv78BXTG7V25oNHCg
9wPhoMtz8K0pFQPQQYWV62hK+vgvI6IdnEHGdkLYF2Z5KgUNNQyTD62KEXhZ
Wm3MekQuR/bqJdG8yKwJ6hAB62jrWCfFHEnKehR7XEiTFAsXEokCZqRvGayM
MoVtGI3gTLKFADryAcjq6IzYimWKQqMl0Akqg1WL1VJO+8RK4KVi8nDqIWrx
NL3q8+BExZXSMurTjGKnzETNwm1Cp+odvAdp3qiYdQepqRxa3cIRgs8QeyX0
SLwPMhjr2mExu4cc4kAdIgh9h6YqmY5dfBOFZJYgvb8awmJVZF0tbgZJlCJq
TPQf5+0MXqZ30a3ca3311Ygo2oY5URqRHJjko+3VNBwRzYzq0dPTKiUDYA2M
k0zW8F/l8ifb8xC9PFgvCOAkNV58YQBWRI9YUblmM/FDLUey2OsJn9CVAv2x
KwpQlmnZKaJkNjC0dpCMKztAQB4Wll2IysoB1pmF9iNJslCnRljHq6rwjHJ3
Mp10UIXPlT9OgkIGMhExtUVZVSy+z6ltXuJ4ZJlmSswig5T9LIWK34AtT6lf
YA2s+9FDQKYM4eT9xZdmVBYjU5Ex5Uqq5lZZgowqiMtdY6Lohr3MWTrLkC6X
GqS6udsHKtN9GDmRgrUBm3aYBHDzNLDjMzV/JuuqNlUuOlZ6XZ/k5+hskvPo
T3XVPrs4GX7DYaILKnP7O+eVt6Lc4RgfyyNiUscApU4KVog2JRiUeT3Fa+gq
VnlkAx75D5+aykIMswxzglOpUeUvlu02Z/ksOD08O/TFeGN2jEoe0EHbKjnX
yqwfmAwHHEoHe6bIe4ITwJ40OwgugLbl0gwBfVGYmcGVyii6D1bW+PDhf/VO
Xr/4+LFhAIhDGFe3JwaHAiSVDB1T456QTF3ME96gM5TzVi6d7h+8vxY5Szn3
B2geQoJEsneRuOf4+ET4wqHw0UUJRggG6fygkxaWx8KXhEURqJ3LYfQZQYIh
mdtLZRwxinx/m1sK0K4x4efAJjdra715v7B+spaP2ecSam1cGAfB2ZPDtTWu
zQ14XvnlRJVFcYOvDoI387zgLh26TJLVPBvjK61Mdw0kKyvCMcgLclA5Pm+y
wAGwfSUr1CUnfPTdgVM0bVOYi0S1lMelbV7Mqbh+NHQx8MAsbW3t0MBZrEKs
oKF2pNHngKtl4RGg3V4K+vtc8SCFSWeZpsTYiytXVROW1DgKoCYoJqV69TWe
wFJJOH+aiCrkaTRtb7hAWEFCc1Iv4DJysocJrvcC15LdLJeagjxsFeb7X0F0
gxk9wJEyiVAjHJLqPIryO++jgPztV7gV8l9Su4UNQPn/wrrB7TQbU7bz6cnV
i8A5O4T2ZRROW+R/PwQBC17LCvMaYw221uHcjoPg6PzNm/MzvEKYVSdUkXp8
0c9nwHthnwTBJ0dchVdCkacREEhcA2wV7XC5Yrfm+uP7Egh5eFHKqMqtpl6f
VXMaPXQNIFii4pwlJXJ9wzdJQ63n3nZcNI5speWkd4XNvk+S2zhLEy7bs3GU
Xp5sWsmo1kDjLJ3PWAOjUOsruh11xNU8d0T05iBowd6O4To9P0awSzdn50Ii
xLxpYV9H9x640aPlZLSlnKEMRg2b2pl/S2B+ThmblL7GoPmccjs1peeEN/j2
OQgLIzu/DXCY2utq+Gn7iur9QebMI87ZK+0rtytrfR4Ihh+VMfzzwDkobwIe
Ei73DFdKctan+ZkSX0RlNMJcCwmA7zxNPyU6iFXma7Dk5D3IpblpVGzBOm33
lGH6Tc/JHpb7RUkop5E0s3tW6SW6rNEDgXtIBbIPVR1gEKxO3qM8jFuLo7sG
qQiNniNVKTGgUakuvydGhf1Od08aJTXc8Sqv7DqvtN3pg/E8RkNLovt8iyOC
OElGzxArOSRLCBpmGEgOC1tpo9ztKxxGHH5feaeBWWVxtaD+s9KWq0OXy3or
GWoJIK5sUU5KX2PkMeEVRmMZPm7WekV99aiTCAX+lKQkTD7sUBqhTv+LMTqU
almIPmvmFPmjyVOSURpD4NjcxPUiIyo1A3tFv22RspZ3awoa3dsrlaAwG0vJ
RKjg00RmPJiEsZhSUDKcY7SkmGITilNhHVTNyZNY7cVUTyBQb6bV2hFWhxeC
Q1tF/U/nN0muxT99X2AZpJAyjSS5mzOLRT6lztqKRt6y1MxyV5Sgvoilz/JY
1SCnqhvCRokU0iHTOyr6Zp7EP88jXTuPlVeVQM2mAJaniZarFHz/0vBxTg1W
dnMtXlu1AsxC+Fl3JfYvXOa2ki8vEZGcUKK+bQfH2lGThYnoO5KujWKv8eNU
qRbGvHFOrdyFU5lK3ieNv9Xd3UNgdnd3CVsslISdVu/8t9U7XzPw3u7uNg0N
Uzw1WbgyH/7qn9FPJCuTOIVZakdbstIpxzbCCLJcJl/ZO3n9IotvMWLvOo8a
BlWuRMHw4wqFeIY6GoM4NlUJIOpjp9rHqgY8nT1RGtP9TF8esaSwF5xyuWGw
pmWZtJxMKvxb1960BAH/tSvNKvYSV/9XPhAZ9cq529q8SJmWRJxnqYqmEJ1G
Nk00pK5EitDqhl5xQ+gJBwtPVTIhOWKpeTJTA4nULFlclhZzyBeKLywveaXS
laUYnuYPCeYPCeYPCebfRoJRKt8kqhcTJIZSnHiqlzivF2nCH2LCv72Y4Cj8
fsbbJ8vA0Kp8o4oxE458MubNNRBUVTocm3zT6BOO3sfYG+PXcnS7ENKn5uIu
AT01MeXIv4Xu89W12SwOq/m0zxfAKCAtsHz46+WAdUjn429NEcskE52YL1lr
zMW0anUmFtPicFFO7VTVp3MhW2NqIphjEuEYUzvDqc0ZecDQJo258kT2sRhy
SmGBI0QBSSokyiYJdO6dUO+rXjjk/Sa/ILxkBsUVJVQZAEBIPjqMSS7mQ3T7
CUj4nPCQ5T0qYEjZsI6humToY8ZFZPeCq5hg+gxFrpj5h3GumENbYB952cY4
Qiv+aIQEr5RYPNKtrzKnnxAhpV2lB9fHVYZEpdRB88M521M5mk9Vw5BO37aL
kuM2ZCwpPQgEJn4XcYO2vin0BQg0Te9JjuFb9feUAmE5o4T6oTPZmUuFMNWI
ngV22ABBcZ5hQAmb2zEiHFm1JUe20dKrpQT0s5NQKGzEJHSRlz8XbmRN4Eaz
i2U/swsKifawEpMwl0Q1l1XXol2eRJZGRIwmqZVOeS+M8yKMmNsmwkhYrTsg
SdhTOm0rQJNPaYYFxTnsnvOCaY+r7qbpTqdAhjEEdITsi6ImSFFEgu7IXFe7
IILCFxBzcH2UrFw9ZIlrjY0TjhtEKomvuhbKcxApu6lEPc2qtPyNq6NrQuE3
NffLloLuKrjPxEe1XiF0OnFplyEX3uR5XfdL5XxQKR0SQDUZcRCJpLdwUOiL
yDJuKMeFuFSWpBXnyK1WrFGYqPCcusdV0BFBR66YvkTWkXGEEc7Oq3Mz/ZRv
lwVDQ/vuIqxFO9QB2pP0jkvA2HK/Gl2GxLOdRiNJ+1AlRlRJFpP/yUiVmBR2
KxneGh2HUpY6+l6FfuDIcJatVgv0pcE7DII4T6wcuB73rLvCwqbA/1W5EStf
AH9XdUU+koNSp3fVNBqoekm9ZaioIDWHXsFQjD2SL69Gq1tdpTVqH5E8SVpF
t8jGrbyYiSohQYDOSpUtEyco1MgUHCYN/PAg8HGRjJpO4ymrfO518OcvpbGj
/Tx3ZWQxTSTCa66mgWHu6PoDGKkWdm60jlWpw1RuqwbWpFmlVkpbdx5zkgt9
TfykXL5VtmJRY4hmsK7Klq5L8rBTfsjTaM8bHKS3xdGkVGiPRyZH4jpR3Wyo
8pNXaxdpFc21VunWn+WqbaqQiaddpIr91FWcrymm+WdMQwYY9k5/OLGzMtVI
5iI6XT1VlpuntaVRKs90jU9c9bqvGy/+arcAD01IjNUQ06QxIaZhPjPbPnWH
QMtCYxiBPhZEUsxwVsZzm1nIzcAYFB1TvvywpYCibkCoyr7PZ7jCahdUXU2J
A5t4g56mocxMVOkASpQkwVvXoRta+aAUu16Dnk2rrggMZu6iL3CuekdWbh2r
m6FxBIfsjIZDuDXotg6kmLmElwwBb5l2JyllPpKrBRdFIGF7cv6fKM/EedWU
Qt2w66nhCw4a4VIRs+VkXMXjG3TxNO710PpKE3dN5d1Gm3o0YS7LiH455Jur
ptfsF0MLgde9phomPTkkYP6WD93a6omqLKDYni50DI9K5fAPH7gYLRai1cfv
dCbWmYRInMdjLGtKRYXgaEltlgmlropZU7nYuNwIq2ggmYmpqE/uKy9e1564
vqKk6Ya3ei9mC9XVyW6Sckl13VFaE15YTi1fudeyFKFizceCim0mWDqqxjol
uYsIxVXpFBdXhTj9MKCG4lLZ3Co2XpRNk6pOuiqR4CrOFjltB8/Tukp/ybBa
+YzVEKfRc0MTI7ZtsRPX8Ax0vLaDQ3bA0pUFgkrgizFpDy48ZVOAApByJpp5
ldvkMGsy/Qk5qsW0vRIzlDhFWN/EylGRiXYOGt83VAKaEuZzfsZmbvy0V1AA
7P6CzDhnpYGQ6nvGmFERnzJXkoJyM6KfArXNqkUQRPjMqkZuq1ZtbWVWrRXL
FuByCXEzDFfXwQJIStp5/ZyO+fq5gF+4rdQiBYpwB69xEWzuwTBTfzcD01cN
k3bw58Z/N1T+A2apJBSUzaZLql9G0mClyv0v6rT+3M/+wwBwUdXvR/6TguL5
pxgK9sFUxRr9e/+kb8L3DxXKqDSbK7E4Q8K5fRl0CGIEtdORTWvpK0U8JImI
vrvG13DZp2fHJ9/9qaO3cXz64sXb54dXRy+xZP8q23AUC5Gmhhyb5uvlbSVF
a6pW3YZen3cJy0+DtrXCaWiJmmCsUU7JvnEyjN6vWxdn8eS8DVp2q7yZje5/
7+1stjqLh7C2QXPbg9ecBpfG9/W1MbIp54dXkWvRNrY8p2GBddVtTMO8eGv2
UruNKwveTns/Sy+d3osUbe+NDVbVvX3KbZhC/zWylSrz/0BpzlvqnwLgOZEj
OGFrg6mOcNlriQXC9JJQjQCVcKceoJp/ZrBcF5GSwmP+FCbh9lT3TUKgZDwj
/7j5PFJJyUoAt03MKiWK6+2ppywr6aVqNWhLPdT4S9fkVWU3HdnRLngblusF
PbziuM3FqPOfZebnxlG0finsicxel7zRBUXD4OK8ZzRiVVUXOLPWQFRvHVEE
D3WpIUzGiVWXjjDoUpm/I3JKWhX+xMsvgzg5WtolYdKe3UWbdA+dCCu1p9xH
hYiXZEUh8eRlCYN1AOBbrAO5boufpc5NVCfSQnt1cb6wxsAM0kVjNLBmCEsK
PeqP01AjUorqaJ4w9lcyyN0UZY90TuE8KIt+/KgWdBO+f5ssWo2mTETkbaOL
Kr1Ww99ttYkV5gU8f5Xy2wtNYrQfXetH5WJY5Kpk/XN9/dL6uaSPr0823m+u
O07YpWcwcc/Bc09LB7Egr8wJ0LE6dGA1U0BddUJO/5ByOyxvfYBqdYBl9TOo
1RBbHvsAtvZko+gAaHCV+osufGGJ0jRu/x474BEWyz2XOJASnHy1oHLs7Uo6
cbdCqz77LHiBpPIbErVoYFV3uco3Wh0yFYziMX552AOgg5Zxl2u3j7AeZehW
lJrpGyWjpDS4dTT+6umcuMy1uuwqs3aeqJ0u5dFy7Sol66w32+KY7iNgpM7C
Rx7VQZNRzVqrEGpY6P8x/4IwzG/Ha0DWH/zvsAcSzyP+oaDkpEQeMCNZ+tqf
Wg//9x+/PHqRf37EdH/yzkbsTbhbPUg8/y74bA+CDw96LQieBO12G/77wNca
itE1goOg8YRT+J7Al6BPLXsNbzO9lk9CjIvCVxbPhm8SE8LXOlvuL3Wvfawf
bOlsS15D+/4gDWcHT56EeVtucRvouwWIJ9XXAkV/DoIt7+Ce2f6VUBmwd1d3
cFplNvVRg2Wnu+iN8mtu9l99Ul7ptSV3pW62IIjWVRPBdcDDv/640mtL0LB+
tk/yGl7u33K2jUM/M1baT81rVGHFLnaYz/s3cSGy12Vv85Mu0v33W4MkKEEF
gWIqGG4ueG312f7J13R3e9Eb5df+ydfUyKKVC/s/5poGFZzs/rvh5N7OQ177
3eBkMzCq0Y+l1/6n4WRHmlDnm4tfW322fzJOPt19yGu/E5zs/kEnHTr5b4aT
+3sPee0PEVu9ZplCyPGhLUXKyWE7KLjWizao2LYnTJCjdmWtqpPjM8pDWtFg
1XUNVq3uJzFZeUOKxBNBtYK5hVAenAVfBtu6+fXiuDirZbzfKOx4S9ks70Qn
+XoYHvZ+e0uairZZR2Ov84OEeD/MxlYN6vzDxrbiIv+wsf1hY6vY2P4TL9SX
2/Zrf9jYSrOpj/8yNjYTD/77EgD+sLEtWqT777eX01c0sf3ryum/dxubc01X
fa30769wwZuuhe7H5a8toAn/c4jCyga9f90b8Hu36P0GNwBtLz+uIKr9cXF+
1Wyr2R3/ZS/O793s+IkujoX9TZQUH3Fx/rhv/39717vcto3Ev/spMMrMNelY
Pke2bCc3vRk3dhK3iZuxnaR37cwVEiGJNUWq/CNH6fgB7oX66b7lxW53AZAg
RdEkJSeKTcxkYlLEAljsLhbA4ocvoW8L1lS/Wn1b9yXVFetbp5q+rUpNb67k
OunbwuXidmfRgrGxOlh+wXhRhOPEiQJzNTlnAXkns4C8c6sxjxdJyLwETUsu
eMOocfWtiQ0fmGu9GoLGwXMPtjrmrO4LMW7zkbc58v5IB75SGP37+O5XeUeN
gqqXR+Tw7jtbXsWKOOo6EFfDySfaScBOwuGTQEN6qBh3PDFgHvmmjnC9uC/k
tQRmbLt5T+CCJXeWu+J+cNdX3FcVu6rutG7W9Zt1/RRLclKzrj+XmtjZGm1r
1vUXlrbOG/vNun5RJdOpWde/8+v6Texss9JenG1tZLKJnW1iZ1VaE5lsYmdv
N3aWsVe4/vMzqyCc92iht3Gxs9keHrteNBzJpT1cv5vwAI/jBwSNuCCbRlhU
CCv2VFiphclH+dlqV7JatvKBcQdxtnsxE242Vkplu5/7n4v3Y3YqBvDLrZVk
ybdeQD/O4n9Vy+O/tnLj+2mDZtFy+01AiOYyu3md8VTMFPh9GbCc1I07MSYs
lyuKJP09HvZHrWQFXV+4kILyTeHDJFhqxUAx6R0KBIpBfL6eyKCpxXUthE0m
HtJekLnjtfs5jkykWZFFDFbbNwbsyU4VtlTYuDkc6LtgoVI4FMq9MjW+8fS1
zObOm7zBouQm2e1vjCl8L7zPhVCYEMF+QrdTx5A+OVIgQdWLu0LtE5no1Dl7
P33PN8C6Y2bLK4KMPcsFW0bxZTN4q4eXsiQr3zzCVHcDSZrNWptIMmsdn2MZ
v0NVuI7vkfI/zHTjnlLCpvlUxrEobmvNDSZMNTeZ4qy1Npoot7HZtFmuwtnR
5CnLzv0XZC3jOSwnTXXOoRilVt2zklm/Zs2p7b1jqrmXhamm84+p9gQAU/a8
ymZ+vrysmFmHJjyFEd5xFmXO7VehgheesgF3AjH/QV7Wz+Br35i1aNK/ylLL
76/NZS2/x/b1s6n8ntuypa6Rgam2C4dpTQxMlayZVG8Sj6nAqt1k1rarZW3M
WomsZfcj75C+VtuhxHTn9LXsWl1O1s+j6o8bVV95qSV3eZcudY1UvdrGL6Y7
oep1VvNV1q/KSnQaK7HyUkvuuy9d6hpZiWpb8ZjulJWoslWYyboKA1OuwktY
iZ3GSqy41NKREDml3n5AxCqy1l2pvbfLrY1FbCziF7SIFfT1b5IPqLiNvn5p
fa2/x3HHZHhxTNFuxTPemXCg1Rz5ph+LY4y6TYTR7UYYdb/UmfrAGzeH6ucP
1YOwgyCFdj9yuJ+Up2WJrnG7KBWmdXBLYVoLytdG1KhBZ1N2j+IQMjsmNX97
Gr5N3b2W3GGHPyEGA9FO3zYJpLmD9e/ou3nT2fAey9S9k3HUFLLV3EGNJw7y
ZkrBfcfG24/NqDPNkkdKtvNYpEwMisfA9qF0sg/zqs++Y91MgxczJx3TpWQK
pJypCxgTEAZqn44zS5FH6ABQ7ogsGZ9y26ErphddZ7eJygBDaqhZOYdFkBM4
9lvoR+K3G8ANsvnoMswQs+/HMitbeNPNopkbRdOQCPHdi0loIQ9jlZJiEmBo
nrqsryA4L3OdYBnhx6a4zPMtLNjDywOhplN5aZwLgxTZIpLOWD5KCsNKo+9U
WiYIL3Y3asfixRTqes4rcKCTVtT1o/Pc6UxaKlxPpeWj9lRaInhPpSVi+EwK
tUP5NJHqEX1mzjqBfSrdcnyfSaE6LMV8HepE+8UU7qpuLjXjVWmJuECVlpg6
q7TUDFql7Am9ShPpmEY6ZrAahc80Ny5LoXjx+5bqMBcXuEm3x4Y7eYGB+XWo
Eh94S63IpLXg5C5wsQv/9kpzsiIj7ywnWZUozFXVYd2tffUgTZXW0tqndhvK
UciEUlauQ2PtKZWPl1xVHdZds6qHU6q05pqVQoTZLKCQiVysXIdGs2QqH594
TzSrevSiSmutWZ3yY1aiVwyj/SrXodEsmcrH9K2sDtWxdT6nZlWP+FNpLTVr
6bl/kW/caFYBhYxi7dy+N7j2mnWQ82sZCmupWXrM2qk7zyryjRvNKqCQ0azd
RrMOntSksOaalcyzdqvMs4p840azCinMjVqL3cF7oVlPbt5j+wo1a7fumFXk
GzeaVUhhbtS675pVtBpWRGEtNWvpedZ+5To0mjW3MdiVwaR7FCS3Quj0LIU1
16w7Fb2gx6yu4Q3uVfEGi2adjWYVUsiMWd17P2bdyZ3ivbreYNGss9GsQgoZ
zdq795p1p3aKl/YGsxeo3Uyh0SxW7fD5gjpUOIN+W62oQ6ECWr8+5NoxKDRR
wTEn59K6WJhVHWZX6ZfMclCFg+nzFHZqUzBPuO9WABXKp7BTi8Lc2X5WhULF
w/Yqpeb+tSiYx5bxvFY1Cl9gvKhho/YNCnfMRlUzTWlO6lTFNOVTqGKa8ilU
MU2LKGTSL5m5iWFYqlPo1qZgGpbM6gPL3gM3n4rMwuI6pJ3AEiRy6lAOzSCf
QhWzUFSHyhQWgxx0l7w4JQtQUIB6sPGAPTs6esVee5ZwYiCDvmU57TG+uoaq
+WLsTYXt+oP+deoIZ3KWE2ls6AkB+45tb2gFgYfHG7KH4c/OBnYU/LGzsaHU
tS18n357nEs6Zk1SJ80dqji9mWugIwahat6R14/GaHHe0nnUIG6kpX5oy4Oq
wXxTHzxg74SPZ/ZZe/sAz020t5+wB5rA9gE8XtPBcuGPbddzvOHs6cYGY212
Mp74HnrSdECfgBjwpGyLW/ChPGnq+a0t+fGhhad/8eD2zPg+oAzP4y5v0VJv
6yi5H4cOtZ+Jycjn6PO3SDwuzl61CFBh6tkWnukeRNQCkolWIkEy9zPENQjI
ItMHZ8+fsb0nHdBDjSygzjYi7sQYKoD1niF9G8cy5B/ReQMDGgqVhUfQeRjy
/mVy2pv1NFveBngU2XOhoW98LxR9zPFScEJWwPPr5ur2lpmnz13PBUvvSEiM
kA+HRGrAnr2/CGRbHO4ncAyqxJdQZ0d9maKuDuWLD/Y3pFs9Dx6RFrH5B0kU
KZhHg6lPLDG1+0KeS5+gfASy3RbCPPQv8e8wgR1AEqdecmgcipISP38GH7qO
CdeaeDZ0x8wWjoUQEcD5IBpP1AlqqhGXwB50styEfJh48CcdxXaVIEHDqe7Q
BiFbFvRHwoocEVCrIYejT4crlIRzAepqh7MY8yLFTymrvhgIH1FK6DARyMzB
fqe7lRH9dH5GaABy8FeHyqEzzbZT6SeHp4epojgjfsjT6FcjKFaeLg/ic/UD
5FRylh3aDhXogXC2LRFy26ErbZQ4x306tVFlQjzQDhU7/gAdGdJrcYWluFAA
8kUqJXccT7MYKoIN3n/c2ZbsAvaHTDh2oGFFwL9DvaBeUD6fkjYS3SObD10v
CO0+XofDVb9+y155V8LvgyaDrE/sECzZRx5b/lbfsYFma5O1QG68yO8T6MQU
rLhEB2nxKBx5vs6jfiPCx5YNSmsDt23ZNVS7rYx925f27cCwb/vwSPZN9kTa
lCHDuJQwuaSHp6G3SnyNUi5NbsZ+acAV7FaiGE3QU1PAET0EUIDOH0RhRHtd
3JplTZgSilZSBJjCkY8rJF4kdVJb/Qqc2ZOc2Tc4swePxBkUhSedJ9soYlFA
GA5QFeNOoygIQcIH5K5ST6aVX1quQ7TVkPmPSAkEmFr/MjAFkUQnIKMrgRqU
zcPXViJRriYAlQnAL4BBduQ5Vnx/EmfJqClZQAKO7YZc0hJI6+UTvgXHlaQh
lIkYIKeyZKOTqUe0likslLQgooUyx7zAyO0LqSqWBtDB+7CQFVgPgs5JOlLV
f+jhb5GLC1R9UmcwGYPE97GVXVYYSxr65vCcvX57foGGYQqcVq3hYQo7SRPL
h2UitI+bqRo4KXnk1RiFpgf5PPKuiJKUd5wUKjOjIG36hHmiYICwBijGiLjR
9yZCEQQTJfxNYBMwCHTAshGxRvqMPRFeiUSEEANJu4weIcQoDZTGEM0INZd6
VkAvWtQl0EmTKEZTSZRdi6CsAd67FYAYxd1uuyAttqWxSALtD5ijXIqAACNM
DoEvHJ6qPzL25PTo+GeqoyGKQYapY8FdNdhL1oMYWwngifz8hXBhUALzit5N
/mCHsjyNHPwOoWZodfXKdi3orhiFxxDkAioJDFfyFdQyABsma/Pc/qBGZtMG
aSwYHA4zVCnXW+yww8Pzdy9orAcDAE00fpJ4OeAm9RxyB2KjBK50qmgrMRmq
SD1k5fhUUkRKGc2uNJp7htHswuN1ur+wYn7UT9Q/PRAXMiFV3K4srmsUtwuP
VBzQRLcIzS+YY+wU0gRFnOMkF9glu8ANfc+K+rG+ntGEAB2F2MMHb8DmpFAP
W6Yst9g02JJjjx6iW490j+CwTWoAg7LZHS3UcD1Q03dBBBoapj9CowM1aqXU
NatvZEsM5SQ7KHVXG0rtmckxaKRc4xTVVO+/RvMO5fThp0VCXllMvlUzMUuN
FAxcpzDbnzuyP3eN/tyBx+tUM7IcgOc2lT2BsaOdgsUDc2nWV3fr2PNCNN84
L5CzjED7agvA+Wiy4wWg01NBuHNDHFthckQjMe/18PZBczyD+VbG/pwJFx4t
dvofsGSYlQyaNCepGQp2IELEuQLfAodhLJA+EY0f5NewvyMXP7Ztd+DFIGeG
c9zqb03G/EMLey22RDBB8+0eyAUOKb+Di0LAYWp50pSGkTF7SstWygoe61HD
MGMLraJhemL/3F1o6E7BDNDwZ9kfGJD10TBgjRKmGjh06YHlWDvf8MEYOThE
69aHRg3RmZxKLAScsKoCDJMuivLeJCC1rWZHiv2OIfYdeCSxP0o51MmQiFJW
UJd4Anzl80mbg9C4ZFQ0RJnhYxZQOU5ZjLhMmq7ISVk8//pnUrciq4OdTtl1
RaR30/YG7R7WMTOyJ6BlgRhz8Fb7wWbcMXpeKT0Yw4CVc/AfS653DK4/hsdr
7R8jnJ7hIQPzZFPIWqRcmDznawzznnimBDwbwTeeRE803VuyW76AduoPF8Fj
bsXSQGYgVvdWX3WdGtn0VIf1PGu2iYaGtFz7s17abSaq3+MiiIINkdxMz1ag
9xBTNYElTdBI1VzMB59JmVFDcwwTC16ew6nqNHkQanB2Zstpzrbsw8dGH27D
ozF95crNMNAsowlhI+Kmt3nlbJC/JGMYLm8AUjprI7aj5NAiLZqAqRW+W6QI
m9KcGP6qki6YowV6RUajOJK3FJGIPMS1PDneYT+25dIvR0xCZ9AOQi4xFwOZ
OXiUGnvAyrq4xU+DF1CgDs2MU5X6AoauS9e7coQ1lA4sdgOX7yxB73CBVQF5
Cuu7luvhCu2ff/75KrKu7CG00g4/Xl9fkzbL4YnQbjm8aCtXgaYVYAOhAlPZ
9cr64wpPMrO/iKehgYyEgBkFAqRy95JBgc9GPuopaMPhOPj0vyCAUjfpB+7j
QgKoAUzXXVe/PhI9kGzPETP95syD39kRd2eOfRV/NvKjKTuCaVPynX3JfYu9
/PTX0AGbpl9/L9zfOfiT7EduRZdxfg6zSHbKpxz6X7/8wRP+kP0UhvrFa+73
PXbGQbzs+J0NA5Nw2Bn+71uBF1f9xxlMX868QOgX/+a4/PfxI8cGnHP/Uvhx
UfaYnQMBHtfzxae/fPwM5mNgo+MPL3yoacDOJ7gCGL/9CawIOw+FcOLCPv3X
t/vs3cztX8bvTu1LB3r1PUig4yRNh2q+93zNYpQ1eP2GRw68jlAkUTLUsGP7
yRobfjkQwuqBrKmex40AuRhhSAUFx/TQHiNMLeEhqbm8xs49vxKgFN8E7MR1
PYUSfDiEJs7Yu5PT05/eHSrgXsGeCQcGoPYprh6CGvwOKgYO4NnJxcn58TOp
T/96c3Z8fv4PelAFvOxsd7b19+z85PnJefslogk/fAFchtFr6AtSKPak29nr
dkBj/w9aeHcPb30CAA== [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.

-->

</rfc>