<?xmlversion='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 " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?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 AttributesRegistry">CoRERegistry">Constrained RESTful Environments (CoRE) Target Attributes Registry</title> <seriesInfoname="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> <dateyear="2023" month="October" day="11"/> <workgroup>CoRE Working group</workgroup> <keyword>Internet-Draft</keyword>year="2024" month="April"/> <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 applyWebweb technologies to constrained environments. Oneimportantsuch 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) inCoAP's Resource Discovery Protocolthe Constrained Application Protocol's (CoAP's) resource discovery process (Section 7.2 ofRFC7252)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 theRD Parameters"RD Parameters" IANARegistryregistry 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 applyWebweb technologies to constrained environments. Oneimportantsuch 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"/> inCoAP's Resource Discovery Protocolthe 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 specificationclarifies(<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 theDesignated Expertdesignated expert for this registry (<xref target="de-instructions"/>). It updates theRD Parameters"RD Parameters" IANARegistryregistry created by <xref target="RFC9176"/> to coordinate with this registry.</t> <t>Withathis 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 inBCP 14BCP 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 newTarget 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, butalsoto 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 makeexceptions,exceptions -- forinstanceinstance, 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 mustinclude:</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"/>stringthat 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 tolower caselowercase here ensures that they are registered in a predictableform).</t>form.)</t> </dd> <dt>Briefdescription:</dt>Description:</dt> <dd><t>a<t>A briefdescription</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">Briefdescription</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 arereservedreserved, 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 requestsPer this document, IANAto addhas 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 <xreftarget="IANA.core-parameters"/>.</t> </li> </ul>target="IANA.core-parameters"/>.</blockquote> </section> </section> <section anchor="security-considerations"> <name>Securityconsiderations</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 CoREWGWorking 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 currentversiondocument addresses additional input andworking group last callWorking Group Last Call comments by <contact fullname="Esko Dijk"/>, <contact fullname="Marco Tiloca"/>, <contact fullname="Thomas Fossati"/>, and <contact fullname="Mohamed Boucadair"/>, as well asarea directorArea 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>