<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="false" docName="draft-bormann-t2trg-rel-impl-02" indexInclude="true" ipr="trust200902" prepTime="2020-09-27T15:32:30" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <!-- xml2rfc v2v3 conversion 3.1.1 -->
  <front>
    <title abbrev="The impl-info relation type">impl-info: A link relation type for disclosing implementation information</title>
    <seriesInfo name="Internet-Draft" value="draft-bormann-t2trg-rel-impl-02" stream="IETF"/>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization ascii="Universitaet Bremen TZI" showOnFrontPage="true">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 month="09" year="2020" day="27"/>
    <keyword>Internet-Draft</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">For debugging, it is often helpful to have information about the
implementation of a peer.  The present specification defines a link
relation type, <tt>impl-info</tt>, that can be used to convey such information
via self-description, such as in the <tt>/.well-known/core</tt> resource.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
        This Internet-Draft is submitted in full conformance with the
        provisions of BCP 78 and BCP 79.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
        Internet-Drafts are working documents of the Internet Engineering Task
        Force (IETF). Note that other groups may also distribute working
        documents as Internet-Drafts. The list of current Internet-Drafts is
        at <eref target="https://datatracker.ietf.org/drafts/current/" brackets="none"/>.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
        Internet-Drafts are draft documents valid for a maximum of six months
        and may be updated, replaced, or obsoleted by other documents at any
        time. It is inappropriate to use Internet-Drafts as reference
        material or to cite them other than as "work in progress."
        </t>
        <t indent="0" pn="section-boilerplate.1-4">
        This Internet-Draft will expire on 31 March 2021.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" toc="include" numbered="true" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">When debugging an interoperability problem, it is often helpful to
have information about the implementation version of a peer.
To enable the disclosure of such information, HTTP defines header
fields such as Server and User-Agent <xref target="RFC7231" format="default" sectionFormat="of" derivedContent="RFC7231"/>.</t>
      <t indent="0" pn="section-1-2">In CoAP <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/>, it is rarely appropriate to send information of
this kind in every request or response.  Instead, the present
specification defines a link relation type, <tt>impl-info</tt>, that can be
used to convey this information via the self-description capabilities
of the <tt>/.well-known/core</tt> resource <xref target="RFC6690" format="default" sectionFormat="of" derivedContent="RFC6690"/> and the CoRE
resource directory <xref target="I-D.ietf-core-resource-directory" format="default" sectionFormat="of" derivedContent="I-D.ietf-core-resource-directory"/>.</t>
    </section>
    <section anchor="iana-considerations" toc="include" numbered="true" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-2-1">This specification requests the registration of the link relation type
<tt>impl-info</tt>.</t>
      <t indent="0" pn="section-2-2">The registration template as per <xref target="RFC8288" format="default" sectionFormat="of" derivedContent="RFC8288"/> follows.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-3">
        <li pn="section-2-3.1">
          <em>Relation Name</em>: <tt>impl-info</tt></li>
        <li pn="section-2-3.2">
          <em>Description</em>: Refers to implementation information that may be
helpful in diagnosing technical problems with the implementation of
the context, such as lists of components and their implementation
versions.</li>
        <li pn="section-2-3.3">
          <em>Reference</em>: <xref target="THIS" format="default" sectionFormat="of" derivedContent="THIS"/></li>
      </ul>
    </section>
    <section anchor="security-considerations" toc="include" numbered="true" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-security-considerations">Security considerations</name>
      <t indent="0" pn="section-3-1">The security considerations listed in Section 9.6 of <xref target="RFC7231" format="default" sectionFormat="of" derivedContent="RFC7231"/>
and the sections referenced there apply.</t>
      <t indent="0" pn="section-3-2">The security considerations listed in Section 11.3 of <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/> apply.
As adding another link to <tt>/.well-known/core</tt> does increase the size
of a response to a GET request for that resource, the mitigation
mentioned in that section to limit the amplification factor
becomes even more important.</t>
      <t indent="0" pn="section-3-3">Disclosing information about an implementation can make it easier for
an attacker to select an attack, or to build automated tools that
search for promising victims.  Fingerprinting techniques can provide
information to attackers that is usable in the same way, so adding
information via self-description may or may not actually exacerbate
this problem.</t>
    </section>
  </middle>
  <back>
    <references pn="section-4">
      <name slugifiedName="name-references">References</name>
      <references pn="section-4.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC8288" target="https://www.rfc-editor.org/info/rfc8288" quoteTitle="true" derivedAnchor="RFC8288">
          <front>
            <title>Web Linking</title>
            <author initials="M." surname="Nottingham" fullname="M. Nottingham">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="October"/>
            <abstract>
              <t indent="0">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 indent="0">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="THIS" target="http://www.ietf.org/internet-drafts/draft-bormann-t2trg-rel-impl-01.txt" quoteTitle="true" derivedAnchor="THIS">
          <front>
            <title>impl-info: A link relation type for disclosing implementation information</title>
            <author initials="C" surname="Bormann" fullname="Carsten Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="March" day="27" year="2020"/>
            <abstract>
              <t indent="0">For debugging, it is often helpful to have information about the implementation of a peer.  The present specification defines a link relation type, "impl-info", that can be used to convey such information via self-description, such as in the "/.well-known/core" resource.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-bormann-t2trg-rel-impl-01"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
      <references pn="section-4.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-core-resource-directory" target="http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-25.txt" quoteTitle="true" derivedAnchor="I-D.ietf-core-resource-directory">
          <front>
            <title>CoRE Resource Directory</title>
            <author initials="Z" surname="Shelby" fullname="Zach Shelby">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Koster" fullname="Michael Koster">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Bormann" fullname="Carsten Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P" surname="Stok" fullname="Peter van der Stok">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Amsuess" fullname="Christian Amsuess">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="July" day="13" year="2020"/>
            <abstract>
              <t indent="0">In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, 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, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-resource-directory-25"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC6690" target="https://www.rfc-editor.org/info/rfc6690" quoteTitle="true" derivedAnchor="RFC6690">
          <front>
            <title>Constrained RESTful Environments (CoRE) Link Format</title>
            <author initials="Z." surname="Shelby" fullname="Z. Shelby">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="August"/>
            <abstract>
              <t indent="0">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="RFC7231" target="https://www.rfc-editor.org/info/rfc7231" quoteTitle="true" derivedAnchor="RFC7231">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
            <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="June"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7231"/>
          <seriesInfo name="DOI" value="10.17487/RFC7231"/>
        </reference>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252" quoteTitle="true" derivedAnchor="RFC7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author initials="Z." surname="Shelby" fullname="Z. Shelby">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Hartke" fullname="K. Hartke">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="June"/>
            <abstract>
              <t indent="0">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 indent="0">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>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgements" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The need for implementation information in the CoRE resource directory
has been identified by Peter van der Stok.  Discussions with Peter and
with <contact fullname="Christian Amsüss"/> led to the present proposal of employing
self-description for this purpose.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author initials="C." surname="Bormann" fullname="Carsten Bormann">
        <organization ascii="Universitaet Bremen TZI" showOnFrontPage="true">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>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAGWUcF8AA5VW0W4bNxB851cs3LfUp8iy49hCE1Sxm8QvgWErKNCiqKm7
lUT4RF5JnhzF0N/0M/qWH+ssTydLspO0AgzfkUtyd3ZmeFmWqWhiyX16rYjM
rCozY8euTwMqjb0lz6WOxlmKi4pp7DwVJuSlC8ZOUjjP2MYmRBb6WXpWejTy
PO/TcMoPu27vpgqXWz3D0YXX45iNZLG1WexFP8kQmqWF3Z4qdERUr9vrZt3T
rPdSqRC1Lf7UpbOYiL5mpUzl02OIvW73FKtueXHnfNGnCxvZW47ZuZyjch37
KVelKtOn36PL9yk4Hz2PA54Ws+Yhd7NK5zE9SJHhD6V0HafO9wFVhj8AZkOf
zjr0psk9jTU1nWkfItutGecnffpozZx9MPHL35HeeMGPhr9dtAE65MZsRGl+
FBWQKaOGSxfiWOdTOjzsHh1101xu4qK/WtAMuALZnGe9k8MXp6uR2kaPqHcs
qS3SYDVNUP54dJod9Q6y3sFJdnx42jtIkzzTpuxTrkfu5/jZdJCmUso2zZ6z
wHH19uykd3LST6wBNzA0fH9xDfCz887TnUXLWsKs9zg+Pu02e2TNVDP8snd4
0KdpjFU2NlwWoR1+0UNaTld4l4MMx3GWO884JLja55wVxnMendTrC6WyLCM9
AoLorFJvhc88qicTpLxPJpIJ5MbStymX1bguKTqa6jlvkhsbuDpSnLLaUYAb
k6aK2XcoMb9CGpikUHFuxiZvogoeG8sBoVKo2hLFPt2s5XKzjzN0BO6WRkx1
4ELSyZ2d84JCjc5vSm5uNAUux1nBIfemksH9JkwHRErCdPO8c8dlmd1ad2ef
C1Q31GLVaeCZmaIoISjIxruizlNuq9/9D0ZGl+rVxg9c+HXK9gFJ0mIGEJ2r
2OuRKUFKYOFGwOprKKuvo7zrM0kYW2iroSO2Gvun+JVF1Z4lZheofXo/HF6u
uzBlXbBXDa/WcF2zxzEopKCPgX02mEgf7++zDRIulx1Bic7c4FKmhIjLZVug
12jsgnSFwitvYGHSPNCh2KrSjVWcIhyikQliHLtAS/6qOUQYgnSncjYwKHVh
YSm62E9FrrilvsUt+o/cUjvcShltZinckkN3+YX1VdNgw0EB7O9xTHDakPdy
mSCWVWfu6he1DlvLVhb4ooF68GGAMBsMGpbyCls8bNk4lOy3YVnhGdJJnidG
HKCVrIw9RkttgNWRTXcWRsa0dBVsAc3bwkB/FDV2ZenuAtY9o2dX7bYfcDM8
6292Ic2fP+CJ2Sseg9/SjK9fr03vZnohvaO1ikCfwuiJbW7nyPnUAoCylV6g
OxOnTykKJKQ0jv5H/hQfbKM0ghpAktsQVwSuwbZjxu9sgz1W0lwXjlLY5lL0
/b3cB8slzOKa89qLJeTf6+W6ocK8JxelBDkpB9umYk47x5LwrlZVS7TQxEGh
bXppHGYBrZaLzv897+Cgc7g6sHGAdp8BoCqKxg+dnNCwDJ19SiGFY9Fc7lmH
xsaC+cwqmVzrAbJW07tfhmuDkC+yRIZWOY05zCDISdMUaQ/+Nzmn0BUAsllp
EJlWaLTyQS/4rID41IjRdqQFU7I0Q5rScXwpaRsB0/nGl+Aj35YrYJtkYjUz
fcvij6jRAA8sQltIx6jzW7wngyyRHq1H98UDMT6qTVkQvr8cjklm5cqQ6lGB
tQdbBQowfWZSRnODImcBrvkWr+xhwcBhLQtBL2WEFXO0V22py61Tao4QP69D
ul9W92iAlOlOL+TLcdVltWuYj8xSBIsk5R8IQcC41iXuCP6kc/Yj1NXcBSu9
AuJ0IY+QiVKDXNhScjFJmD6Wi7rvk61nIzC5eLVn3d6yYbJlwCXgfMNPVlWJ
B9NjD8bdHOA04ACQAoqQVEGjBV0y7niaa7l2PF1Hdwu4hRV1SC7Q+E0TBfWp
9PqTeAxKJzhWKd/Kr/bOph6qMthnMAtf/glh7/lrKpsbaeOqE1wqF2BoEIW4
r1sI7I9gbjQhONYe8fiu+RfOv+mP5wwAAA==

-->

</rfc>
