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

<!-- [CS] updated by Chris 10/12/23 -->

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 3.2.2) -->
<?rfc compact="yes"?>
<?rfc comments="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-core-target-attr-06" category="info" number="9423" submissionType="IETF" category="info" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.18.1 -->
  <front>
    <title abbrev="CoRE Target Attributes Registry">CoRE Registry">Constrained RESTful Environments (CoRE) Target Attributes Registry</title>

    <seriesInfo name="Internet-Draft" value="draft-ietf-core-target-attr-06"/> name="RFC" value="9423"/>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <date year="2023" month="October" day="11"/>
    <workgroup>CoRE Working group</workgroup>
    <keyword>Internet-Draft</keyword> year="2024" month="March"/>
    <area>art</area>
    <workgroup>core</workgroup>

<keyword>CoAP</keyword>
<keyword>Web Linking</keyword>
<keyword>Resource Discovery</keyword>

    <abstract>
      <?line 57?>
<t>The Constrained RESTful Environments (CoRE) specifications apply Web web
technologies to constrained environments.
One important such important technology is Web Linking (RFC 8288), which CoRE
specifications use as the basis for a number of discovery protocols, such as the
Link Format (RFC 6690) in CoAP's Resource Discovery Protocol the Constrained Application Protocol's (CoAP's) resource discovery process (Section 7.2
of RFC7252) RFC 7252) and the Resource Directory (RD, RFC 9176).</t> (RD) (RFC 9176).
</t>
      <t>Web Links can have target attributes, the names of which are not
generally coordinated by the Web Linking specification (Section 2.2 of
RFC 8288).
This document introduces an IANA registry for coordinating names of target
attributes when used in CoRE.
It updates the RD Parameters "RD Parameters" IANA Registry registry created by RFC 9176 to coordinate with
this registry.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-core-target-attr/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        core Working Group mailing list (<eref target="mailto:core@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/core/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/core/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/core-wg/core-target-attr"/>.</t>
    </note>
  </front>
  <middle>
    <?line 74?>
<section anchor="intro">
      <name>Introduction</name>
      <t>The Constrained RESTful Environments (CoRE) specifications apply Web web
technologies to constrained environments.
One important such important technology is Web Linking <xref target="RFC8288"/>, which CoRE
specifications use as the basis for a number of discovery protocols, such as the
Link Format <xref target="RFC6690"/> in CoAP's Resource Discovery Protocol the Constrained Application Protocol's (CoAP's) resource discovery process (<xref section="7.2" sectionFormat="of" target="RFC7252"/>) and the Resource Directory (RD)
<xref target="RFC9176"/>.</t>
      <t>Web Links can have target attributes.
The original Web Linking specification (<xref section="3" sectionFormat="of" target="RFC5988"/>) did not attempt
to coordinate names of target attributes except for providing common
target attributes for use in the Link HTTP header.
The current revision of that specification clarifies (<xref section="2.2" sectionFormat="of" target="RFC8288"/>):</t> target="RFC8288"/>) clarifies as follows:</t>
<!-- DNE; verified -->
      <blockquote>
        <t>This specification does not attempt to coordinate the name of target
   attributes, their cardinality, or use.  Those creating and
   maintaining serialisations <bcp14>SHOULD</bcp14> coordinate their target attributes
   to avoid conflicts in semantics or syntax and <bcp14>MAY</bcp14> define their own
   registries of target attributes.</t>
      </blockquote>
      <t>This document introduces an IANA registry for coordinating names of target
attributes when used in CoRE, with
specific instructions for the Designated Expert designated expert for this registry (<xref target="de-instructions"/>).
It updates the RD Parameters "RD Parameters" IANA Registry registry created by <xref target="RFC9176"/> to coordinate with
this registry.</t>
      <t>With a this registry now available, registration of target attributes is strongly encouraged.
The incentive is that an unregistered attribute name might be registered with a different meaning at any time.</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&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
        <?line -18?>
</section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This specification creates
      <t>Per this specification, IANA has created a new Target Attributes "Target Attributes" registry in
the "Constrained RESTful Environments (CoRE) Parameters" registry group <xref target="IANA.core-parameters"/>, with the policy
"Expert Review" (<xref (Section <xref section="4.5" sectionFormat="of" sectionFormat="bare" target="RFC8126"/> of RFC 8126 <xref target="BCP26"/>).</t>
      <section anchor="de-instructions">
        <name>Instructions for the Designated Expert</name>
        <t>The expert is requested to guide the registrant towards reasonably
short target attribute names where the shortness will help conserve
resources in constrained systems, but also to also be frugal in the
allocation of very short names, keeping them in reserve for
applications that are likely to enjoy wide use and can make good use
of their shortness.</t>
        <t>The expert is also instructed to direct the registrant to provide a
specification (<xref (Section <xref section="4.6" sectionFormat="of" target="BCP26"/>), sectionFormat="bare" target="RFC8126"/> of RFC 8126 <xref target="BCP26"/>) but can make exceptions, exceptions --
for instance instance, when a specification is not available at the time of
registration but is likely forthcoming.</t>
        <t>Any questions or issues that might interest a wider audience might be
raised by the expert on the core-parameters@ietf.org mailing list for
a time-limited discussion.
This might include security considerations, or opportunities for
orchestration, e.g., when different names with similar intent are
being or could be registered.</t>
        <t>If the expert becomes aware of target attributes that are deployed and
in use, they may also initiate a registration on their own if
they deem that such a registration can avert potential future collisions.</t>
      </section>
      <section anchor="structure-of-entries">
        <name>Structure of Entries</name>
        <t>Each entry in the registry must include:</t> include the following:</t>
        <dl newline="true">
          <dt>Attribute Name:</dt>
          <dd>
            <t>a lower case
            <t>A lowercase ASCII string <xref target="STD80"/> string that starts with a letter and can
contain digits and hyphen-minus characters afterward
(<tt>[a-z][-a-z0-9]*</tt>).
(Note that <xref target="RFC8288"/> requires target attribute names to be
interpreted in a case-insensitive way; the restriction to lower case lowercase
here ensures that they are registered in a predictable form).</t> form.)</t>
          </dd>
          <dt>Brief description:</dt> Description:</dt>
          <dd>
            <t>a
            <t>A brief description</t> description.</t>
          </dd>
          <dt>Change Controller:</dt>
          <dd>
            <t>see
            <t>See Section <xref section="2.3" sectionFormat="of" target="BCP26"/></t> sectionFormat="bare" target="RFC8126"/> of RFC 8126 <xref target="BCP26"/>.</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t>a
            <t>A reference document that provides a description of the target
attribute, including the semantics for when the target attribute
appears more than once in a link.</t>
          </dd>
        </dl>
      </section>
      <section anchor="initial-entries">
        <name>Initial Entries</name>
        <t>Initial entries in this registry are listed in <xref target="pre-reg"/>.</t>
        <table anchor="pre-reg">
          <name>Initial Entries in the Target Attributes Registry</name>
          <thead>
            <tr>
              <th align="left">Attribute Name</th>
              <th align="left">Brief description</th> Description</th>
              <th align="left">Change Controller</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">href</td>
              <td align="left">reserved (not useful as target attribute name)</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref target="RFC6690"/></td>
            </tr>
            <tr>
              <td align="left">anchor</td>
              <td align="left">reserved (not useful as target attribute name)</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref target="RFC6690"/></td>
            </tr>
            <tr>
              <td align="left">rel</td>
              <td align="left">reserved (not useful as target attribute name)</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref target="RFC6690"/></td>
            </tr>
            <tr>
              <td align="left">rev</td>
              <td align="left">reserved (not useful as target attribute name)</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref target="RFC6690"/></td>
            </tr>
            <tr>
              <td align="left">hreflang</td>
              <td align="left">(Web Linking)</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref target="RFC8288"/></td>
            </tr>
            <tr>
              <td align="left">media</td>
              <td align="left">(Web Linking)</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref target="RFC8288"/></td>
            </tr>
            <tr>
              <td align="left">title</td>
              <td align="left">(Web Linking)</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref target="RFC8288"/></td>
            </tr>
            <tr>
              <td align="left">type</td>
              <td align="left">(Web Linking)</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref target="RFC8288"/></td>
            </tr>
            <tr>
              <td align="left">rt</td>
              <td align="left">resource type</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref section="3.1" sectionFormat="of" target="RFC6690"/></td>
            </tr>
            <tr>
              <td align="left">if</td>
              <td align="left">interface description</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref section="3.2" sectionFormat="of" target="RFC6690"/></td>
            </tr>
            <tr>
              <td align="left">sz</td>
              <td align="left">maximum size estimate</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref section="3.3" sectionFormat="of" target="RFC6690"/></td>
            </tr>
            <tr>
              <td align="left">ct</td>
              <td align="left">Content-Format hint</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref section="7.2.1" sectionFormat="of" target="RFC7252"/></td>
            </tr>
            <tr>
              <td align="left">obs</td>
              <td align="left">observable resource</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref section="6" sectionFormat="of" target="RFC7641"/></td>
            </tr>
            <tr>
              <td align="left">hct</td>
              <td align="left">HTTP-CoAP URI mapping template</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref section="5.5" sectionFormat="of" target="RFC8075"/></td>
            </tr>
            <tr>
              <td align="left">osc</td>
              <td align="left">hint: resource only accessible using OSCORE</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref section="9" sectionFormat="of" target="RFC8613"/></td>
            </tr>
            <tr>
              <td align="left">ep</td>
              <td align="left">Endpoint Name (with rt="core.rd-ep")</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref section="9.3" sectionFormat="of" target="RFC9176"/></td>
            </tr>
            <tr>
              <td align="left">d</td>
              <td align="left">Sector (with rt="core.rd-ep")</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref section="9.3" sectionFormat="of" target="RFC9176"/></td>
            </tr>
            <tr>
              <td align="left">base</td>
              <td align="left">Registration Base URI (with rt="core.rd-ep")</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref section="9.3" sectionFormat="of" target="RFC9176"/></td>
            </tr>
            <tr>
              <td align="left">et</td>
              <td align="left">Endpoint Type (with rt="core.rd-ep")</td>
              <td align="left">IETF</td>
              <td align="left">
                <xref section="9.3" sectionFormat="of" target="RFC9176"/></td>
            </tr>
          </tbody>
        </table>
        <t>A number of names are reserved reserved, as they are used for parameters in
links other than target attributes.
A further set of target attributes is predefined in <xref target="RFC8288"/> and is
imported into this registry.</t>
        <t><xref section="9.3" sectionFormat="of" target="RFC9176"/> created the "RD Parameters" IANA registry.
This document requests
Per this document, IANA to add has added the following note to that registry:</t>
        <ul empty="true">
          <li>
            <t>Note:
            <blockquote>Note: In accordance with [this document], RFC 9423, all entries with the "A" flag set, including new ones, <bcp14>MUST</bcp14> also be registered in the "Target Attributes" registry <xref target="IANA.core-parameters"/>.</t>
          </li>
        </ul> target="IANA.core-parameters"/>.</blockquote>

      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security considerations</name> Considerations</name>
      <t>The security considerations of <xref target="RFC8288"/> apply, as do those of the
discovery specifications <xref target="RFC6690"/>, <xref target="RFC7252"/>, and <xref target="RFC9176"/>.</t>
    </section>
  </middle>
  <back>

    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC8288">
          <front>
            <title>Web Linking</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="October" year="2017"/>
            <abstract>
              <t>This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types").</t>
              <t>It also defines the serialisation of such links in HTTP headers with the Link header field.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8288"/>
          <seriesInfo name="DOI" value="10.17487/RFC8288"/>
        </reference>
        <reference anchor="BCP26">
          <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="STD80">
          <front>
            <title>ASCII format for network interchange</title>
            <author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/>
            <date month="October" year="1969"/>
          </front>
          <seriesInfo name="STD" value="80"/>
          <seriesInfo name="RFC" value="20"/>
          <seriesInfo name="DOI" value="10.17487/RFC0020"/>
        </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.8288.xml"/>

<referencegroup anchor="BCP26" target="https://www.rfc-editor.org/info/bcp26">
  <xi:include
      href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
</referencegroup>
<referencegroup anchor="STD80" target="https://www.rfc-editor.org/info/std80">
  <xi:include
      href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/>
</referencegroup>

<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"/>

        <reference anchor="IANA.core-parameters" target="https://www.iana.org/assignments/core-parameters">
          <front>
            <title>Constrained RESTful Environments (CoRE) Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC6690">
          <front>
            <title>Constrained RESTful Environments (CoRE) Link Format</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
            <date month="August" year="2012"/>
            <abstract>
              <t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6690"/>
          <seriesInfo name="DOI" value="10.17487/RFC6690"/>
        </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, 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="RFC8075">
          <front>
            <title>Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)</title>
            <author fullname="A. Castellani" initials="A." surname="Castellani"/>
            <author fullname="S. Loreto" initials="S." surname="Loreto"/>
            <author fullname="A. Rahman" initials="A." surname="Rahman"/>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <author fullname="E. Dijk" initials="E." surname="Dijk"/>
            <date month="February" year="2017"/>
            <abstract>
              <t>This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8075"/>
          <seriesInfo name="DOI" value="10.17487/RFC8075"/>
        </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="RFC5988">
          <front>
            <title>Web Linking</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="October" year="2010"/>
            <abstract>
              <t>This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5988"/>
          <seriesInfo name="DOI" value="10.17487/RFC5988"/>
        </reference>
        <reference anchor="RFC9176">
          <front>
            <title>Constrained RESTful Environments (CoRE) Resource Directory</title>
            <author fullname="C. Amsüss" initials="C." role="editor" surname="Amsüss"/>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
            <author fullname="M. Koster" initials="M." surname="Koster"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="P. van der Stok" initials="P." surname="van der Stok"/>
            <date month="April" year="2022"/>
            <abstract>
              <t>In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9176"/>
          <seriesInfo name="DOI" value="10.17487/RFC9176"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6690.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.8075.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.5988.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9176.xml"/>

      </references>
    </references>
    <?line 232?>
<section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The CoRE WG Working Group had been discussing setting up a registry for target
attributes since the final touches were made on <xref target="RFC6690"/>.
The update of the Web Linking specification to <xref target="RFC8288"/> provided the
formal setting, but it took until <contact fullname="Jaime Jiménez"/> provided the set of
initial registrations to generate a first draft version of this specification.
The current version document addresses additional input and working group last
call Working Group Last
Call comments by
<contact fullname="Esko Dijk"/>,
<contact fullname="Marco Tiloca"/>,
<contact fullname="Thomas Fossati"/>,
and
<contact fullname="Mohamed Boucadair"/>,
as well as area director Area Director review comments from
<contact fullname="Rob Wilton"/>.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact initials="J." surname="Jiménez" fullname="Jaime Jiménez">
        <organization>Ericsson</organization>
        <address>
          <email>jaime@iki.fi</email>
        </address>
      </contact>
      <t>Jaime provided the list of initial registrations.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81a3XLbxhW+36fY0he1UoIVKVmW2NiJLMmJMrblSvJ4Utcz
WQJLciMQi2AB0bSsd+lFb/oazYv1O2cBEICk2E2mTjWWRS72/Oz5P2cRBIG4
HMstIXKTx3osHwspD+zpkTxX2Uzncj/PMzMpcu3kqZ4Zl2croSaTTAPqY/si
GyZqAaRRpqZ5YHQ+DUKb6SBnmEABJogVYHJxT0b4MJajzdFWsIl/QywVKS26
sdwbPtwR4kKvljaLxvI4yXWWAMMhIRahysfSJFMrQFarBTYcnT8Vy1nJ4mub
XZhkJmeZLVIhLnVS6DHOuVAmHssesfQ1MTew2ayH9ZnJ58VkLJnX5ezPXZ6F
SM1Yvslt2JfOZqA5dfi0WvgPoV2kKsz5w0InuXsrhCryuc2IaIBfKb1cDlTm
cp3IJzZbqCThJ+BhLF8l5lJnzuQ//zOXTzINNPL8b8e8gc6oceCX1uVTFc7l
1tbm9vYmPwtNvhqXAH7BRqBzGIx2tx7slStFAuWM5TeaiK54MZ3bBPv+tL0X
bI+GwWi4G+xs7Y2G/FB7OYVqYr/O3xuSkhChTbzC6VRBeZ7vlFlo+Z1Z/Pyv
RL8XfBiVmPcqNzYZy6PMhM5Z4qzE+SMBfG0uzGBqBPFWIuXtHlua2UsT6Ujm
cy1jGJa0Uyjb5EbFMvOmxvjdQIiEBJlDdiTp06cHu6Pd3TGgEtI/lp4cvBzt
jPlUAUxGJQokHX9/NGaA4WgHX8/OD3c3633KhcY0No02hSBza9Pa2dnb9LQC
/8gvPxw9GJEpqbT8vrM9HEs7cSWHmw8fjOU8z9MAJ323Kld3hlvY5Mjy/MqD
vcZJAhtHfpkcYyyzSIggCKSakDDCXIhzCOsAR8NXk0B4p0dn59MilkfJpcls
wmYp75N3bEiX6tBMTeilKFWaxiv5Wk9ErsN5YmM7M/Dq3JJ6aoS6gWggThIt
zSKFL6gkl66AVdbAK2kcoZPPPPPyPviWpJmNvlzODfYSH6LDRuE0BM9anygH
FBCqVDIpFhOdkQ1EBuKBl6zIROCLNiYnJNIeTBA9+ZRV4WmShjZgO6C3//KP
FKicLbJQy8Ma1csSlbx/pkNiRD4cjASolZrckCrxptgAzrDVAvj+6WGfNnK4
2oA5Vqd2cJ5EztWllj6MSFWHyz5jI/9xdCovEJVhyeZiphOdqRj6CC0in0kQ
DiM5WTFMU6Yt4a2ZHw1GQCpqgQ9gGBAlAnNBmoMs8sxGRQjaYPB4/8V+5VIr
lndNlWjUPPoziPUZwDUCFDQWeemeHg3EcV6Fby+uQ/lSZcCAyO08pSpPyBBB
uzxXJT1vbtWR5RIRWeTEesXewFv8wkRRrIU4Lg/Cpy5/ru7x8a7Fo8aP+P/2
jauroPTx6+vP5x0l1TJuXV9/qo9cXXW8JKA4d339i14CYll0ff2J7jFgddnM
zGAJ8S/Z/JqZLRJA0IiVxFFkInIpQq0XaS7aBtax7QYDUr8LdZqzgH0uItqU
2pHIbu6mbaQcSJDOz1L+9vz8pZxrFenMHycssozcD1WUccQxEZ5DEe0jhbHK
8A1YG4fzLi3XZrIxFuJq/FNhc30tHpPhs4+3UUUWWBrH7/hXFYIa3g08nSBl
EA8UQ8QoM/rSn3RA9CxOzF5MsoHuCRoZPsnxy6rSGdK1caX1nn178urZYYcB
oL8hTsIDTtWlhfbgYtPYhHBOCNehgkhy1BPEhluB0js2uuf738tIT+GHJU67
5EqojBvmDi0PxOeKjH0fzCr1YBk4feDy1kO6ONTOzHywP3qX6iwvnzQCINlE
pIMmOGzh18bd0ik/Jey+xiJCTc1HYpdQEMo5NYl1v1WS3e5QZJwQbjJDKNUJ
6tFMzXTkPcMkIaSPoop2sUtA+kXikeoMzNaIvMEuzGyey4mWjS1Lz2FkplPN
frbQis2Q0SF5oq4cUCJABWx8HKZkUv34DIFmQ1K34WTv+auz817f/5UvTvjz
6dFfXx2fHh3S57Nv9589qz+Icoc38vWnNeTByfPnRy8OPTBWZWtJ9GDDeELW
3Dt5eX588mL/Wc8HlKaFUo0AdU1IaDh3mmnSpXIi0i6EiLzJoeL99z+G21Dw
H6hyHQ73oGX/ZXf4cBtfyEI9NZtAI/4rTAd9XppqlREWlCDw/dTkitIIMoib
w68Q0zIS5BdvSDJvx/LLSZgOtx+XC3Tg1mIls9Yiy+zmyg1gL8Rblm4hU0uz
td6RdJvf/e9b3yu5Nxa//CqmqBIMd796DONhV6IyAs1J2YC0Co263rglGnvH
c5Sw9fKWDrr2LYMUA1vsfWq5snb13hoJt72kc2J5wM1sWu/jMoP8heikFvF1
JXplzDlFetLLXjP7bA8ecPapWicOOeLePbTknxTGru51Y5b3Nu0fc6T5qdCO
QGDcswLSZVRVWEkodS0V+SWEiGYSUWclYI6A7oaaMi4vyUwZCW9LtMOagUXP
dZxy4aazSy2yslTh9NIs59wK7Cxg98AJT3C2dLtpVsxQkvhML+AiNqyjHhdK
nitmoo94olOKQdi7IBiQI7IkK3K0uC7tfNTLqNm90HBIENPJjxaeSbLgwg++
ShXTQl1oObM2olXBNQRlvPqUg65smflK+l7CEddlN0Vc9d1SiTvrrO3BTtcY
vJBq5nztRMfqCzIKoq0Q4n1aVB23MGWJUiUTitfEGMVramNaqYXoAKAUEpDn
cxRlkDBOvY8gz1bEAiW6zhW6FK3PGBwzsQNMkFxRPBeR0cRalVEE1O/W3VYp
Revruo4X1eMjnimRmnlSwbpl9lGuLQyJnOrywlHRV/ZiFTthXEDaTqM2RHXF
BriOLFxs2ZSaiIJGH77QFDYL57qSSF/qwWzQ96Jd577SB8jFHXiIOaDnZQIR
E03Mcj1TxFE7j0KQx9Pm2ScaEqawtSTzvDW318Yb6TS2K0pIqAYNl0A+q0BC
q8oQaYgDN1WdoiFZl27STAVDRRpu4/uX9m6yNXQOYC+1dCwaC02LvMhISXHM
9TV5AgWpMzb8wjN/lHA5KMQRDdF04uNt0xPAa+Fq3XCZfelSFaLOroO1fEGT
LzEGW7FdaiqR4aH7ZwfHx1RU8egISZZKT3Z+KvIhttxVVUqsUZFnlU+XQzAE
HqhwZnLHD+arFEoNYN0FeqW5ohkPlXNqij8UDAF2/4c3Knj/9k2A/zeDvbdf
/IDIjOUXlsvrdZfHTQOHWbi+uytocogDfLO2oEKAz0cRXMM+uVBbqtVfSqnR
KX1oAPhaHEDDIRggRVYZCWuVLKVRuDEBEIuAhQMANaSUYJ5AU+hpubDheOIl
PukuC3EwV8mM+3uUmHGsM9rptJbNDmqrE7aEONXsLmGpyqz6ui63mOkyKFLm
blD17Zted061MPul8ZSBv9G1UDRkT10DrsEIBddeCA+Wc5citwi1lxBpscq6
fg5a23K1oP1CXTXWFu0TiyvVeXUFaQd4yP34B9k2a/lB3hC8/MWfD/KG/LFW
C/cWABCdQ9otHGVqjOR9SgeIHFTuqDtMdQMANO7vMnJ1Vc5kYey3kkUeQqL8
7GQzHbchPhfZy9+DLOk2hkXUEPcbE5yNmzA3cNxBthHJbiO7QAhRTYjPQ5bv
0H4HsqtUtyA+D1mk3DZEVUF3GfovydZjvMFQ+sl7bWFE1kw7EJyipoqC9afE
qY+THd1G1r3vQCzUO7MoUJSY90htqDUXVMv8BrJbt5ENu0KmyIroHpSj2zlO
fzfRj5N9OBjVYqYLDhAmsnbi2hBYQLjgpFyr+TeQ3alI7mwPS/PicNE+7gce
nQY0ipavTo8h8tT3UHqRxrdJ+2NkH/j2tbx3q4VsXdiGIKmO1wflwYgK0Rs6
QxIoHHFxcnZwcnr0KWT3KqI7w63GaXXagThKotSSQjn73ucKMcsf8Q31IIsC
nfY2WgAfIVubFF2p1KeNuhBnPJn/OL3fRnZChXET4rRZxj+hp6TjO7n4lWR1
14FqIZ9TlPrfCPlqLO+VlZVPCo96nVKtajXufn2ih7J0v3Gj4+tyXzGXqdtf
5fiijmfMfEmxHveaRMR8v2KxLfNl5C2j7300TBnvcDq/c2ZLdTkP1svKsZEd
qEcxTvhbLn6O+r87N/4FkVWDaJ51tSbWvfbovXt/WQ6LysE23RREHssUtadd
8mye+x/r6/cKD3q5x5I6I3qXhDzbZpGfS5A1/P1Na9L6ts/zz6qkrqdlvf2e
RHFDtxt5s9CnmZ5NaObDU1DudSfdPocR3FB+Y2p357wOojy7fUpw2/yxmkHe
OVogTbSVSXecPOSNSGp0teP7G7G+U+zcRnbvD/u04q8C/WR5fedHl7YTFV7A
tsOLxC5jHc00zzBvcE9e5M1fR496ie1dV3e39E7PN3KuaGDBww4/U+GLppxv
ZIq0eUXB88gbVzOOLhu8tfDdYm4LGqfIJfWqCxVR3L9xNH9N4W9Yqr7v7ktJ
2F1Lts2XWQSjjCuW/eTM0OzNXsgCXWIM2Kv2KzXXHRylw4pb34fhASq/QMAz
lqnJXC75taKqZe0Optu3k9VW+BQijqPgE0WG9vHUM6VpKHS7bL5dJWPl6IUs
ui8o336SkxV8/+rIXVh5aH68wBn6tPBcZaGV54bGptXa+dwuYHhPraOrQl6l
+RHttnN4QCSfQEkqUibzD0lbMfctiIGqnGZC2xmPrtc8TDO7IDSndiJfmzi3
yTXp8j/HfPRy/yYAAA==

-->
</rfc>