Internet-Draft The impl-info relation type September 2020
Bormann Expires 31 March 2021 [Page]
Network Working Group
Intended Status:
C. Bormann
Universität Bremen TZI

impl-info: A link relation type for disclosing implementation information


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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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

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

This Internet-Draft will expire on 31 March 2021.

Table of Contents

1. Introduction

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 [RFC7231].

In CoAP [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, impl-info, that can be used to convey this information via the self-description capabilities of the /.well-known/core resource [RFC6690] and the CoRE resource directory [I-D.ietf-core-resource-directory].

2. IANA Considerations

This specification requests the registration of the link relation type impl-info.

The registration template as per [RFC8288] follows.

3. Security considerations

The security considerations listed in Section 9.6 of [RFC7231] and the sections referenced there apply.

The security considerations listed in Section 11.3 of [RFC7252] apply. As adding another link to /.well-known/core 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.

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.

4. References

4.1. Normative References

Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, , <>.
Bormann, C., "impl-info: A link relation type for disclosing implementation information", Work in Progress, Internet-Draft, draft-bormann-t2trg-rel-impl-01, , <>.

4.2. Informative References

Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, "CoRE Resource Directory", Work in Progress, Internet-Draft, draft-ietf-core-resource-directory-25, , <>.
Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, , <>.
Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, , <>.
Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, , <>.


The need for implementation information in the CoRE resource directory has been identified by Peter van der Stok. Discussions with Peter and with Christian Amsüss led to the present proposal of employing self-description for this purpose.

Author's Address

Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen