<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" submissionType="IETF" docName="draft-ietf-httpapi-api-catalog-08" number="9727" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" updates="" obsoletes="" prepTime="2025-06-13T14:05:58" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-httpapi-api-catalog-08" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9727" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="api-catalog: A Well-Known URI">api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs</title>
    <seriesInfo name="RFC" value="9727" stream="IETF"/>
    <author initials="K." surname="Smith" fullname="Kevin Smith">
      <organization showOnFrontPage="true">Vodafone</organization>
      <address>
        <email>kevin.smith@vodafone.com</email>
        <uri>https://www.vodafone.com</uri>
      </address>
    </author>
    <date month="06" year="2025"/>
    <area>WIT</area>
    <workgroup>httpapi</workgroup>
    <keyword>API</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines the "api-catalog" well-known URI and link
      relation. It is intended to facilitate automated discovery and usage of
      published Application Programming Interfaces (APIs). A request to the
      api-catalog resource will return a document providing information about,
      and links to, the Publisher's APIs.</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 is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9727" brackets="none"/>.
        </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) 2025 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 Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised 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>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-goals-and-non-goals">Goals and Non-Goals</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-notational-conventions">Notational Conventions</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" 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-using-the-api-catalog-well-">Using the "api-catalog" Well-Known URI</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" 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-the-api-catalog-link-relati">The api-catalog Link Relation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-using-additional-link-relat">Using Additional Link Relations</xref></t>
              </li>
            </ul>
          </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-the-api-catalog-document">The API Catalog Document</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-api-catalog-contents">API Catalog Contents</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-api-catalog-formats">API Catalog Formats</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nesting-api-catalog-links">Nesting API Catalog Links</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-considerations">Operational Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-accounting-for-apis-distrib">Accounting for APIs Distributed Across Multiple Domains</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-internal-use-of-api-catalog">Internal Use of api-catalog for Private APIs</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scalability-guidelines">Scalability Guidelines</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-monitoring-and-maintenance">Monitoring and Maintenance</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.5">
                <t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent="5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-integration-with-existing-a">Integration with Existing API Management Frameworks</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conformance-to-rfc-8615">Conformance to RFC 8615</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-suffix">Path Suffix</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-formats-and-associated-medi">Formats and Associated Media Types</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-api-catalog-well-known-">The api-catalog Well-Known URI</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-api-catalog-link-relatio">The api-catalog Link Relation</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-api-catalog-profile-uri">The api-catalog Profile URI</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <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.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-api-catalog-documen">Example API Catalog Documents</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-using-linkset-with-link-rel">Using Linkset with Link Relations Defined in RFC 8631</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-using-linkset-with-bookmark">Using Linkset with Bookmarks</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-other-api-catalog-formats">Other API Catalog Formats</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.4">
                <t indent="0" pn="section-toc.1-1.10.2.4.1"><xref derivedContent="A.4" format="counter" sectionFormat="of" target="section-appendix.a.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nesting-api-catalog-links-2">Nesting API Catalog Links</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">An application may publish APIs
to encourage requests for interaction from external parties. Such
APIs must be discovered before they may be used, i.e., the external
party needs to know what APIs a given Publisher exposes, their
purpose, any policies for usage, and the endpoint to interact with
each API. To facilitate automated discovery of this information 
and automated usage of the APIs, this document proposes:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-2">
        <li pn="section-1-2.1">
          <t indent="0" pn="section-1-2.1.1">a well-known URI <xref target="RFC8615" format="default" sectionFormat="of" derivedContent="WELL-KNOWN"/>, "api-catalog", that is encoded as a URI 
reference to an API catalog document describing a Publisher's API 
endpoints.</t>
        </li>
        <li pn="section-1-2.2">
          <t indent="0" pn="section-1-2.2.1">a link relation <xref target="RFC8288" format="default" sectionFormat="of" derivedContent="WEB-LINKING"/>, "api-catalog", of which the target
resource is the Publisher's API catalog document.</t>
        </li>
      </ul>
      <section anchor="goals" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-goals-and-non-goals">Goals and Non-Goals</name>
        <t indent="0" pn="section-1.1-1">The primary goal of this document is to facilitate the automated discovery
of a Publisher's public API endpoints, along with metadata that describes the
purpose and usage of each API, by specifying a well-known URI that returns an
API catalog document. The API catalog document is primarily machine-readable
to enable automated discovery and usage of APIs, and it may also include links
to human-readable documentation (see the example in <xref target="api-catalog-example-rfc8615" format="default" sectionFormat="of" derivedContent="Appendix A.1"/>).</t>
        <t indent="0" pn="section-1.1-2">Non-goals: This document does not mandate paths for API endpoints, i.e., it does not mandate that my_example_api's endpoint should be
<tt>https://www.example.com/.well-known/api-catalog/my_example_api</tt>, nor 
even to be hosted at www.example.com (although it is not forbidden to 
do so).</t>
      </section>
      <section anchor="notational-conventions" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-notational-conventions">Notational Conventions</name>
        <t indent="0" pn="section-1.2-1">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 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
These words may also appear in this document in
lower case as plain English words, absent their normative meanings.
        </t>
        <t indent="0" pn="section-1.2-2">The terms "content negotiation" and "status code" are from <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="HTTP"/>.
The term "well-known URI" is from <xref target="RFC8615" format="default" sectionFormat="of" derivedContent="WELL-KNOWN"/>.
The term "link relation" is from <xref target="RFC8288" format="default" sectionFormat="of" derivedContent="WEB-LINKING"/>.</t>
        <t indent="0" pn="section-1.2-3">The term "Publisher" refers to an organisation, company, or
        individual that publishes one or more APIs for use by external third
        parties.  A fictional Publisher named "example" is used throughout
        this document.  The examples use the Fully Qualified Domain Names
        (FQDNs) "www.example.com", "developer.example.com", "apis.example.com", "apis.example.net", "gaming.example.com", and 
        "iot.example.net", where the .com and .net Top-Level Domains (TLDs) and various
        subdomains are simply used to illustrate that the "example" Publisher may
        have their API portfolio distributed across various domains for which
        they are the authority. 
Scenarios where the Publisher "example" is
        not the authority for a given <em>.example.</em> domain are
        made explicit in the text.</t>
        <t indent="0" pn="section-1.2-4">In this document, "API" refers to the specification resources required 
for an external party (or in the case of "private" APIs, an internal 
party) to implement software that uses the Publisher's API.</t>
        <t indent="0" pn="section-1.2-5">The specification recommends the use of TLS. Hence, "HTTPS" and 
"https://" are used throughout.</t>
      </section>
    </section>
    <section anchor="usage" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-using-the-api-catalog-well-">Using the "api-catalog" Well-Known URI</name>
      <t indent="0" pn="section-2-1">The api-catalog well-known URI is intended for HTTPS servers that 
publish APIs.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-2">
        <li pn="section-2-2.1">
          <t indent="0" pn="section-2-2.1.1">The API catalog <bcp14>MUST</bcp14> be named "api-catalog" in a well-known location
 as described by <xref target="RFC8615" format="default" sectionFormat="of" derivedContent="WELL-KNOWN"/>.</t>
        </li>
        <li pn="section-2-2.2">
          <t indent="0" pn="section-2-2.2.1">The location of the API catalog document is decided by the Publisher. 
The /.well-known/api-catalog URI provides a convenient reference to
that location.</t>
        </li>
      </ul>
      <t indent="0" pn="section-2-3">A Publisher supporting this URI:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-4">
        <li pn="section-2-4.1">
          <t indent="0" pn="section-2-4.1.1"><bcp14>SHALL</bcp14> resolve an HTTPS GET request to /.well-known/api-catalog and
return an API catalog document (as described in <xref target="api-catalog" format="default" sectionFormat="of" derivedContent="Section 4"/>).</t>
        </li>
        <li pn="section-2-4.2">
          <t indent="0" pn="section-2-4.2.1"><bcp14>SHALL</bcp14> resolve an HTTPS HEAD request to /.well-known/api-catalog
with a response including a Link header with the relation(s) defined
in <xref target="link-relation" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
        </li>
      </ul>
    </section>
    <section anchor="link-relation" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-the-api-catalog-link-relati">The api-catalog Link Relation</name>
      <t indent="0" pn="section-3-1">This document introduces a new link relation <xref target="RFC8288" format="default" sectionFormat="of" derivedContent="WEB-LINKING"/>, 
"api-catalog". This identifies a target resource that represents a
list of APIs available from the Publisher of the link context. 
The target resource URI may be /.well-known/api-catalog or any
other URI chosen by the Publisher. For example, the Publisher
"example" could include the api-catalog link relation in the HTTP
header and/or content payload when responding to a request to
<tt>https://www.example.com</tt>:</t>
      <sourcecode type="http-message" markers="false" pn="section-3-2">
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Location: /index.html
Link: &lt;/my_api_catalog.json&gt;; rel=api-catalog
Content-Length: 356

&lt;!DOCTYPE HTML&gt;
  &lt;html&gt;
    &lt;head&gt;
      &lt;title&gt;Welcome to Example Publisher&lt;/title&gt;
    &lt;/head&gt;
    &lt;body&gt;
      &lt;p&gt;
       &lt;a href="my_api_catalog.json" rel="api-catalog"&gt;
        Example Publisher's APIs
       &lt;/a&gt;
      &lt;/p&gt;
      &lt;p&gt;(remainder of content)&lt;/p&gt;
    &lt;/body&gt;
  &lt;/html&gt;
</sourcecode>
      <section anchor="using-additional-link-relations" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-using-additional-link-relat">Using Additional Link Relations</name>
        <t indent="0" pn="section-3.1-1">When used in an API catalog document, the "item" <xref target="RFC6573" format="default" sectionFormat="of" derivedContent="RFC6573"/> link relation identifies a target resource that represents an
API that is a member of the API catalog.</t>
        <t indent="0" pn="section-3.1-2">Other link relations may be utilised in an API catalog to convey
metadata descriptions for API links.</t>
      </section>
    </section>
    <section anchor="api-catalog" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-the-api-catalog-document">The API Catalog Document</name>
      <t indent="0" pn="section-4-1">The API catalog is a document listing a Publisher's APIs. The
Publisher may host the API catalog document at any URI(s) 
they choose. 
   For example, the API catalog document URI of
   <tt>https://www.example.com/my_api_catalog.json</tt> can be requested directly or
   via a request to <tt>https://www.example.com/.well-known/api-catalog</tt>, which
   the Publisher will resolve to <tt>https://www.example.com/my_api_catalog</tt>.</t>
      <section anchor="api-catalog-contents" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-api-catalog-contents">API Catalog Contents</name>
        <t indent="0" pn="section-4.1-1"> The API catalog <bcp14>MUST</bcp14> include hyperlinks to API
endpoints. It is <bcp14>RECOMMENDED</bcp14> that the API catalog also includes
useful metadata, such as usage policies, API version information, links to the
OpenAPI Specification <xref target="OAS" format="default" sectionFormat="of" derivedContent="OAS"/> definitions for each API, etc. If the Publisher does not 
include that metadata directly in the API catalog document, they 
<bcp14>SHOULD</bcp14> make that metadata available at the API endpoint URIs they 
have listed (see <xref target="api-catalog-example-linkset-bookmarks" format="default" sectionFormat="of" derivedContent="Appendix A.2"/> for 
an example).</t>
      </section>
      <section anchor="api-catalog-formats" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-api-catalog-formats">API Catalog Formats</name>
        <t indent="0" pn="section-4.2-1">The Publisher <bcp14>MUST</bcp14> publish the API catalog document in the Linkset
format <tt>application/linkset+json</tt> (<xref section="4.2" sectionFormat="of" target="RFC9264" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9264#section-4.2" derivedContent="RFC9264"/>). 
The Linkset <bcp14>SHOULD</bcp14> include a profile parameter (<xref section="5" sectionFormat="of" target="RFC9264" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9264#section-5" derivedContent="RFC9264"/>) with a Profile URI <xref target="RFC7284" format="default" sectionFormat="of" derivedContent="RFC7284"/> value of "https://www.rfc-editor.org/info/rfc9727"
to indicate the Linkset is representing an API catalog document as
defined above. <xref target="api-catalog-example-linkset" format="default" sectionFormat="of" derivedContent="Appendix A"/> includes example API catalog documents 
based on the Linkset format.</t>
        <t indent="0" pn="section-4.2-2">The Publisher <bcp14>MAY</bcp14> make additional formats available via 
content negotiation (<xref section="12" sectionFormat="of" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-12" derivedContent="HTTP"/>) to their 
/.well-known/api-catalog location. A non-exhaustive list of such 
formats that support the automated discovery and machine (and 
human) usage of a Publisher's APIs is listed at
<xref target="api-catalog-other-formats" format="default" sectionFormat="of" derivedContent="Appendix A.3"/>. If a Publisher already lists their
APIs in a format other than Linkset, but wishes to utilise the 
/.well-known/api-catalog URI, then:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2-3">
          <li pn="section-4.2-3.1">
            <t indent="0" pn="section-4.2-3.1.1">They <bcp14>MUST</bcp14> also implement a Linkset with, at minimum, hyperlinks to
API endpoints; see <xref target="api-catalog-example-linkset-bookmarks" format="default" sectionFormat="of" derivedContent="Appendix A.2"/>.</t>
          </li>
          <li pn="section-4.2-3.2">
            <t indent="0" pn="section-4.2-3.2.1">They <bcp14>MAY</bcp14> support content negotiation at the 
/.well-known/api-catalog URI to allow for the return of their existing format.</t>
          </li>
        </ul>
      </section>
      <section anchor="nest" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-nesting-api-catalog-links">Nesting API Catalog Links</name>
        <t indent="0" pn="section-4.3-1">An API catalog may itself contain links to other API catalogs by using
        the "api-catalog" relation type for each link.  An example of this is
        given in <xref target="api-catalog-example-linkset-nesting" format="default" sectionFormat="of" derivedContent="Appendix A.4"/>.</t>
      </section>
    </section>
    <section anchor="operations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-operational-considerations">Operational Considerations</name>
      <section anchor="multiple_domains" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-accounting-for-apis-distrib">Accounting for APIs Distributed Across Multiple Domains</name>
        <t indent="0" pn="section-5.1-1">A Publisher ("example") may have their APIs hosted across multiple 
domains that they manage, e.g., at <tt>www.example.com</tt>, 
<tt>developer.example.com</tt>, <tt>apis.example.com</tt>, 
<tt>apis.example.net</tt>, etc. They may also use a third-party API 
hosting provider that hosts APIs on a distinct domain.</t>
        <t indent="0" pn="section-5.1-2">To account for this scenario, it is <bcp14>RECOMMENDED</bcp14> that:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-3">
          <li pn="section-5.1-3.1">
            <t indent="0" pn="section-5.1-3.1.1">The Publisher also publish the api-catalog well-known URI at each
 of their API domains, e.g., <tt>https://apis.example.com/.well-known/api-catalog</tt>, 
 <tt>https://developer.example.net/.well-known/api-catalog</tt>, etc.</t>
          </li>
          <li pn="section-5.1-3.2">
            <t indent="0" pn="section-5.1-3.2.1">An HTTPS GET request to any of these URIs returns the same result,
 namely, the API catalog document.</t>
          </li>
          <li pn="section-5.1-3.3">
            <t indent="0" pn="section-5.1-3.3.1">The Publisher choose one of their
instances of /.well-known/api-catalog as a canonical reference to 
the location of the latest API catalog since the physical location of the API catalog document is decided by the Publisher and may change. The Publisher's other 
instances of /.well-known/api-catalog should redirect to this 
canonical instance of /.well-known/api-catalog to ensure the latest
API catalog is returned.</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.1-4">For example, if the Publisher's primary API portal is 
<tt>https://apis.example.com</tt>, then 
<tt>https://apis.example.com/.well-known/api-catalog</tt> should resolve to 
the location of the Publisher's latest API catalog document. If the 
Publisher is also the domain authority for <tt>www.example.net</tt>, 
which also hosts a selection of their APIs, then a request to 
<tt>https://www.example.net/.well-known/api-catalog</tt> should redirect
to <tt>https://apis.example.com/.well-known/api-catalog</tt>.</t>
        <t indent="0" pn="section-5.1-5">If the Publisher is not the domain authority for <tt>www.example.net</tt>,
   then the Publisher's API Catalog <bcp14>MAY</bcp14> include a link to the
  API catalog of the third-party that is the domain authority for <tt>www.example.net</tt>. For example, the API catalog available 
at <tt>https://apis.example.com/.well-known/api-catalog</tt> may list APIs 
hosted at <tt>apis.example.com</tt> and also link to the API catalog hosted 
at <tt>https://www.example.net/.well-known/api-catalog</tt> using the 
"api-catalog" link relation:</t>
        <sourcecode type="json" markers="false" pn="section-5.1-6">
{
 "linkset": [
  {
   "anchor": "https://www.example.com/.well-known/api-catalog",
   "item": [
    {
     "href": "https://developer.example.com/apis/foo_api"
    },
    {
     "href": "https://developer.example.com/apis/bar_api"
    },
    {
     "href": "https://developer.example.com/apis/cantona_api"
    }
   ],
   "api-catalog": "https://www.example.net/.well-known/api-catalog"
  }
 ]
}
</sourcecode>
      </section>
      <section anchor="internal-use" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-internal-use-of-api-catalog">Internal Use of api-catalog for Private APIs</name>
        <t indent="0" pn="section-5.2-1">A Publisher may wish to use the api-catalog well-known URI on their 
internal network to signpost authorised users (e.g., company 
employees) towards internal/private APIs not intended for third-party
use. This scenario may incur additional security considerations as 
noted in <xref target="security" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t>
      </section>
      <section anchor="scalability" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-scalability-guidelines">Scalability Guidelines</name>
        <t indent="0" pn="section-5.3-1">In cases where a Publisher has a large number of APIs potentially
deployed across multiple domains, two challenges may arise:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3-2">
          <li pn="section-5.3-2.1">
            <t indent="0" pn="section-5.3-2.1.1">Maintaining the catalog entries to ensure they are up to date and
correcting any errors.</t>
          </li>
          <li pn="section-5.3-2.2">
            <t indent="0" pn="section-5.3-2.2.1">Restricting the catalog size to help reduce network and 
client-processing overheads.</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.3-3">In both cases, a Publisher may benefit from grouping their APIs,
providing an API catalog document for each group and using the main
API catalog hosted at /.well-known/api-catalog to provide links to
these. For example, a Publisher may decide to group their APIs
according to a business category (e.g., "gaming APIs", "anti-fraud
APIs", etc.), a technology category (e.g., "IOT", "networks", "AI",
etc.), or any other criterion.

   This grouping may be implicit where the Publisher has already published
   their APIs across multiple domains, e.g., at <tt>gaming.example.com</tt>,
   <tt>iot.example.net</tt>, etc.</t>
        <t indent="0" pn="section-5.3-4"><xref target="nest" format="default" sectionFormat="of" derivedContent="Section 4.3"/> shows how the API catalog at
/.well-known/api-catalog can use the api-catalog link relation to
point to other API catalogs.</t>
        <t indent="0" pn="section-5.3-5">The Publisher <bcp14>SHOULD</bcp14> consider caching and compression 
techniques to reduce the network overhead of large API catalogs.</t>
      </section>
      <section anchor="maintenance" numbered="true" removeInRFC="false" toc="include" pn="section-5.4">
        <name slugifiedName="name-monitoring-and-maintenance">Monitoring and Maintenance</name>
        <t indent="0" pn="section-5.4-1">Publishers are <bcp14>RECOMMENDED</bcp14> to follow operational best practice when
hosting API catalog(s), including, but not limited to:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.4-2">
          <li pn="section-5.4-2.1">
            <t indent="0" pn="section-5.4-2.1.1">Availability. The Publisher should monitor availability of the API
catalog and consider alternate means to resolve requests to
/.well-known/api-catalog during planned downtime of hosts.</t>
          </li>
          <li pn="section-5.4-2.2">
            <t indent="0" pn="section-5.4-2.2.1">Performance. Although the performance of APIs listed in an API
catalog can demand high transactions per second and low-latency
response, the retrieval of the API catalog itself to discover those
APIs is less likely to incur strict performance demands. That said,
the Publisher should monitor the response time to fulfil a request
for the API catalog and determine any necessary improvements (as
with any other Web resource the Publisher serves). For large API
catalogs, the Publisher should consider the techniques described in
<xref target="scalability" format="default" sectionFormat="of" derivedContent="Section 5.3"/>.</t>
          </li>
          <li pn="section-5.4-2.3">
            <t indent="0" pn="section-5.4-2.3.1">Usage. Since the goal of the api-catalog well-known URI is to
facilitate discovery of APIs, the Publisher may wish to correlate
requests to the /.well-known/api-catalog URI with subsequent requests
to the API URIs listed in the catalog.</t>
          </li>
          <li pn="section-5.4-2.4">
            <t indent="0" pn="section-5.4-2.4.1">Current data. The Publisher should include the removal of stale API
entries from the API catalog as part of their API release lifecycle.
The Publisher <bcp14>MAY</bcp14> decide to include metadata regarding legacy API
versions or deprecated APIs to help users of those APIs discover
up-to-date alternatives.</t>
          </li>
          <li pn="section-5.4-2.5">
            <t indent="0" pn="section-5.4-2.5.1">Correct metadata. The Publisher should include human and/or
automated checks for syntax errors in the API catalog. Automated
checks include format validation (e.g., to ensure valid JSON syntax)
and linting to enforce business rules, such as removing duplicate
entries and ensuring descriptions are correctly named with valid
values. A proofread of the API catalog as part of the API release
lifecycle is <bcp14>RECOMMENDED</bcp14> to detect any errors in business grammar
(for example, an API entry that is described with valid syntax, but
has been allocated an incorrect or outdated description.)</t>
          </li>
          <li pn="section-5.4-2.6">
            <t indent="0" pn="section-5.4-2.6.1">Security best practice. See <xref target="security" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t>
          </li>
        </ul>
      </section>
      <section anchor="integration" numbered="true" removeInRFC="false" toc="include" pn="section-5.5">
        <name slugifiedName="name-integration-with-existing-a">Integration with Existing API Management Frameworks</name>
        <t indent="0" pn="section-5.5-1">A Publisher may already utilise an API management framework to
produce their API portfolio. These frameworks typically include the
publication of API endpoint URIs, deprecation and redirection of
legacy API versions, API usage policies and documentation, etc.
The api-catalog well-known URI and API catalog document are intended
to complement API management frameworks by facilitating the discovery
of the framework's outputs -- API endpoints, usage policies, and
documentation -- and are not intended to replace any existing
API discovery mechanisms the framework has implemented.</t>
        <t indent="0" pn="section-5.5-2">Providers of such frameworks may include the production of an API
catalog and the publication of the /.well-known/api-catalog URI as a
final pre-release (or post-release) step in the release management
workflow. The following steps are recommended.</t>
        <t indent="0" pn="section-5.5-3">If the /.well-known/api-catalog URI has not been published previously, the framework provider should:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.5-4">
          <li pn="section-5.5-4.1">
            <t indent="0" pn="section-5.5-4.1.1">Collate and check the metadata for each API that will be included
in the API catalog. This metadata is likely to already exist in the
framework.</t>
          </li>
          <li pn="section-5.5-4.2">
            <t indent="0" pn="section-5.5-4.2.1">Determine which metadata to include in the API catalog following
the requirements set out in <xref target="api-catalog-contents" format="default" sectionFormat="of" derivedContent="Section 4.1"/> and the
considerations set out in <xref target="operations" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
          </li>
          <li pn="section-5.5-4.3">
            <t indent="0" pn="section-5.5-4.3.1">Map the chosen metadata to the format(s) described in
<xref target="api-catalog-formats" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. The structure suggested in                                
<xref target="api-catalog-example-linkset-bookmarks" format="default" sectionFormat="of" derivedContent="Appendix A.2"/> may be followed where only the hyperlinks to APIs are to be 
included in the API catalog. Where 
possible, the API catalog should include further metadata per the 
guidance in <xref target="api-catalog-contents" format="default" sectionFormat="of" derivedContent="Section 4.1"/>; in which case, the structure
suggested in <xref target="api-catalog-example-linkset" format="default" sectionFormat="of" derivedContent="Appendix A"/> can be utilised and
adapted (ensuring compliance to <xref target="RFC9264" format="default" sectionFormat="of" derivedContent="RFC9264"/>) to reflect the nature
of the chosen metadata.</t>
          </li>
          <li pn="section-5.5-4.4">
            <t indent="0" pn="section-5.5-4.4.1">Publish the /.well-known/api-catalog URI following the guidance set
out in <xref target="usage" format="default" sectionFormat="of" derivedContent="Section 2"/>.</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.5-5">If the /.well-known/api-catalog URI has previously been published,
the framework provider should:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.5-6">
          <li pn="section-5.5-6.1">
            <t indent="0" pn="section-5.5-6.1.1">Include a step in the release management lifecycle to refresh the
API catalog following any changes in API hyperlinks or published
metadata. This could include placing triggers on certain metadata
fields, so that as they are updated in pre-production on the API
framework, the updates are pushed to a pre-production copy of the API
catalog to be pushed live when the release is published by the
framework.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="conform-rfc8615" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-conformance-to-rfc-8615">Conformance to RFC 8615</name>
      <t indent="0" pn="section-6-1">The requirements in <xref section="3" sectionFormat="of" target="RFC8615" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8615#section-3" derivedContent="WELL-KNOWN"/> for defining 
Well-Known URIs are met as described in the
following subsections.</t>
      <section anchor="path-suffix" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-path-suffix">Path Suffix</name>
        <t indent="0" pn="section-6.1-1">The api-catalog URI <bcp14>SHALL</bcp14> be appended to the /.well-known/
path-prefix for "well-known locations".</t>
      </section>
      <section anchor="formats-and-associated-media-types" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-formats-and-associated-medi">Formats and Associated Media Types</name>
        <t indent="0" pn="section-6.2-1">A /.well-known/api-catalog location <bcp14>MUST</bcp14> support the Linkset
<xref target="RFC9264" format="default" sectionFormat="of" derivedContent="RFC9264"/> format of application/linkset+json and <bcp14>MAY</bcp14>
also support the other formats via content negotiation.</t>
      </section>
    </section>
    <section anchor="iana" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="the-api-catalog-well-known-uri" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-the-api-catalog-well-known-">The api-catalog Well-Known URI</name>
        <t indent="0" pn="section-7.1-1">This specification registers the "api-catalog" well-known URI in
        the "Well-Known URIs" registry as defined by <xref target="RFC8615" format="default" sectionFormat="of" derivedContent="WELL-KNOWN"/>.</t>
        <dl spacing="compact" newline="false" indent="3" pn="section-7.1-2">
          <dt pn="section-7.1-2.1">URI Suffix:</dt>
          <dd pn="section-7.1-2.2">api-catalog</dd>
          <dt pn="section-7.1-2.3">Reference:</dt>
          <dd pn="section-7.1-2.4">RFC 9727</dd>
          <dt pn="section-7.1-2.5">Status:</dt>
          <dd pn="section-7.1-2.6">permanent</dd>
          <dt pn="section-7.1-2.7">Change Controller:</dt>
          <dd pn="section-7.1-2.8">IETF</dd>
        </dl>
      </section>
      <section anchor="the-api-catalog-link-relation" numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
        <name slugifiedName="name-the-api-catalog-link-relatio">The api-catalog Link Relation</name>
        <t indent="0" pn="section-7.2-1">This specification registers the "api-catalog" link relation in the "Link Relation Types" registry by
        following the procedures per <xref section="2.1.1.1" sectionFormat="of" target="RFC8288" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8288#section-2.1.1.1" derivedContent="WEB-LINKING"/>.</t>
        <dl spacing="compact" newline="false" indent="3" pn="section-7.2-2">
          <dt pn="section-7.2-2.1">Relation Name:</dt>
          <dd pn="section-7.2-2.2">api-catalog</dd>
          <dt pn="section-7.2-2.3">Description:</dt>
          <dd pn="section-7.2-2.4">Refers to a list of APIs available from the
          Publisher of the link context.</dd>
          <dt pn="section-7.2-2.5">Reference:</dt>
          <dd pn="section-7.2-2.6">RFC 9727</dd>
        </dl>
      </section>
      <section anchor="the-api-catalog-profile-uri" numbered="true" removeInRFC="false" toc="include" pn="section-7.3">
        <name slugifiedName="name-the-api-catalog-profile-uri">The api-catalog Profile URI</name>
        <t indent="0" pn="section-7.3-1">This specification registers "https://www.rfc-editor.org/info/rfc9727" in the "Profile URIs"
        registry according to <xref target="RFC7284" format="default" sectionFormat="of" derivedContent="RFC7284"/>.</t>
        <dl spacing="compact" newline="false" indent="3" pn="section-7.3-2">
          <dt pn="section-7.3-2.1">Profile URI:</dt>
          <dd pn="section-7.3-2.2">https://www.rfc-editor.org/info/rfc9727</dd>
          <dt pn="section-7.3-2.3">Common Name:</dt>
          <dd pn="section-7.3-2.4">API catalog</dd>
          <dt pn="section-7.3-2.5">Description:</dt>
          <dd pn="section-7.3-2.6">A Profile URI to request or signal a
          Linkset representing an API catalog.</dd>
          <dt pn="section-7.3-2.7">Reference:</dt>
          <dd pn="section-7.3-2.8">RFC 9727</dd>
        </dl>
      </section>
    </section>
    <section anchor="security" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">For all scenarios:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-2">
        <li pn="section-8-2.1">
          <t indent="0" pn="section-8-2.1.1">TLS <bcp14>SHOULD</bcp14> be used, i.e., make /.well-known/api-catalog available
exclusively over HTTPS, to ensure no tampering of the API catalog.</t>
        </li>
        <li pn="section-8-2.2">
          <t indent="0" pn="section-8-2.2.1">The Publisher <bcp14>SHOULD</bcp14> take into account the security considerations
from <xref section="4" sectionFormat="of" target="RFC8615" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8615#section-4" derivedContent="WELL-KNOWN"/>.</t>
        </li>
        <li pn="section-8-2.3">
          <t indent="0" pn="section-8-2.3.1">The Publisher <bcp14>SHOULD</bcp14> perform a security and privacy review of the
API catalog prior to deployment to ensure it does not leak personal,
business, or other sensitive metadata, nor expose any vulnerability
related to the APIs listed.</t>
        </li>
        <li pn="section-8-2.4">
          <t indent="0" pn="section-8-2.4.1">The Publisher <bcp14>SHOULD</bcp14> enforce read-only privileges for external
requests to .well-known/api-catalog and for internal systems and
roles that monitor the .well-known/api-catalog URI. Write privileges
<bcp14>SHOULD</bcp14> only be granted to roles that perform updates to the API 
catalog and/or the forwarding rewrite rules for the
.well-known/api-catalog URI.</t>
        </li>
        <li pn="section-8-2.5">
          <t indent="0" pn="section-8-2.5.1">As with any Web offering, it is <bcp14>RECOMMENDED</bcp14> to apply rate-limiting
measures to help mitigate abuse and prevent denial-of-service
attacks on the API catalog endpoint.</t>
        </li>
      </ul>
      <t indent="0" pn="section-8-3">For the public-facing APIs scenario, security teams <bcp14>SHOULD</bcp14> 
additionally audit the API catalog to ensure no APIs intended solely
for internal use have been mistakenly included. For example, a
catalog hosted on <tt>https://developer.example.com</tt> should not expose
unnecessary metadata about any internal domains
(e.g., <tt>https://internal.example.com</tt>).</t>
      <t indent="0" pn="section-8-4">For the internal/private APIs scenario, the Publisher <bcp14>SHOULD</bcp14> take
steps to ensure that appropriate controls, such as Cross-Origin Resource Sharing (CORS) policies and
access control lists, are in place to ensure only authorised roles
and systems may access an internal api-catalog well-known URI.</t>
      <t indent="0" pn="section-8-5">A comprehensive API catalog that is regularly audited may assist
the Publisher in decommissioning "zombie" APIs, i.e., legacy/obsolete
APIs that should no longer be available. Such APIs represent a
security vulnerability as they are unlikely to be supported,
monitored, patched, or updated.</t>
      <t indent="0" pn="section-8-6">Note the registration of domain names and associated policies is out
of scope of this document.</t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC9110" to="HTTP"/>
    <displayreference target="RFC8288" to="WEB-LINKING"/>
    <displayreference target="RFC8615" to="WELL-KNOWN"/>
    <displayreference target="I-D.kelly-json-hal" to="HAL"/>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110" quoteTitle="true" derivedAnchor="HTTP">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC6573" target="https://www.rfc-editor.org/info/rfc6573" quoteTitle="true" derivedAnchor="RFC6573">
          <front>
            <title>The Item and Collection Link Relations</title>
            <author fullname="M. Amundsen" initials="M." surname="Amundsen"/>
            <date month="April" year="2012"/>
            <abstract>
              <t indent="0">RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6573"/>
          <seriesInfo name="DOI" value="10.17487/RFC6573"/>
        </reference>
        <reference anchor="RFC7284" target="https://www.rfc-editor.org/info/rfc7284" quoteTitle="true" derivedAnchor="RFC7284">
          <front>
            <title>The Profile URI Registry</title>
            <author fullname="M. Lanthaler" initials="M." surname="Lanthaler"/>
            <date month="June" year="2014"/>
            <abstract>
              <t indent="0">This document defines a registry for profile URIs to be used in specifications standardizing profiles.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7284"/>
          <seriesInfo name="DOI" value="10.17487/RFC7284"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="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 indent="0">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>
        <reference anchor="RFC9264" target="https://www.rfc-editor.org/info/rfc9264" quoteTitle="true" derivedAnchor="RFC9264">
          <front>
            <title>Linkset: Media Types and a Link Relation Type for Link Sets</title>
            <author fullname="E. Wilde" initials="E." surname="Wilde"/>
            <author fullname="H. Van de Sompel" initials="H." surname="Van de Sompel"/>
            <date month="July" year="2022"/>
            <abstract>
              <t indent="0">This specification defines two formats and associated media types for representing sets of links as standalone documents. One format is based on JSON, and the other is aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support the discovery of sets of links.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9264"/>
          <seriesInfo name="DOI" value="10.17487/RFC9264"/>
        </reference>
        <reference anchor="RFC8288" target="https://www.rfc-editor.org/info/rfc8288" quoteTitle="true" derivedAnchor="WEB-LINKING">
          <front>
            <title>Web Linking</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="October" year="2017"/>
            <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="RFC8615" target="https://www.rfc-editor.org/info/rfc8615" quoteTitle="true" derivedAnchor="WELL-KNOWN">
          <front>
            <title>Well-Known Uniform Resource Identifiers (URIs)</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="May" year="2019"/>
            <abstract>
              <t indent="0">This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8615"/>
          <seriesInfo name="DOI" value="10.17487/RFC8615"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="APIsjson" target="https://apisjson.org/format/apisjson_0.19.txt" quoteTitle="true" derivedAnchor="APIsjson">
          <front>
            <title>API Discovery Format</title>
            <author initials="K" surname="Lane">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Willmott">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2024" month="November" day="6"/>
          </front>
          <annotation>Latest version available at <eref target="https://apisjson.org/" brackets="angle"/>.</annotation>
        </reference>
        <reference anchor="I-D.kelly-json-hal" target="https://datatracker.ietf.org/doc/html/draft-kelly-json-hal-11" quoteTitle="true" derivedAnchor="HAL">
          <front>
            <title>JSON Hypertext Application Language</title>
            <author initials="M." surname="Kelly" fullname="Mike Kelly">
              <organization showOnFrontPage="true">Stateless</organization>
            </author>
            <date month="October" day="19" year="2023"/>
            <abstract>
              <t indent="0">   This document proposes a media type for representing resources and
   their relations with hyperlinks.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-kelly-json-hal-11"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="OAS" target="https://spec.openapis.org/oas/latest" quoteTitle="true" derivedAnchor="OAS">
          <front>
            <title>OpenAPI Specification v3.1.0</title>
            <author initials="D" surname="Miller" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H" surname="Andrews" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J" surname="Whitlock" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L" surname="Mitchell" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Gardiner" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Quintero" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Kistler" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R" surname="Handl" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R" surname="Ratovsky" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2024" month="October" day="24"/>
          </front>
          <annotation>Latest version available at <eref target="https://spec.openapis.org/oas/latest.html" brackets="angle"/>.</annotation>
        </reference>
        <reference anchor="RESTdesc" target="https://restdesc.org/about/descriptions" quoteTitle="true" derivedAnchor="RESTdesc">
          <front>
            <title>RESTdesc</title>
            <author initials="R" surname="Verborgh">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E" surname="Mannens">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R" surname="Van de Walle">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T" surname="Steiner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2025"/>
          </front>
        </reference>
        <reference anchor="RFC8631" target="https://www.rfc-editor.org/info/rfc8631" quoteTitle="true" derivedAnchor="RFC8631">
          <front>
            <title>Link Relation Types for Web Services</title>
            <author fullname="E. Wilde" initials="E." surname="Wilde"/>
            <date month="July" year="2019"/>
            <abstract>
              <t indent="0">Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web services" or "Web APIs". This specification defines link relations that represent relationships from Web services or APIs to resources that provide documentation, descriptions, metadata, or status information for these resources. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. Metadata provides information about a service's context. This specification also defines a link relation to identify status resources that are used to represent information about service status.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8631"/>
          <seriesInfo name="DOI" value="10.17487/RFC8631"/>
        </reference>
        <reference anchor="WebAPIext" target="https://webapi-discovery.github.io/rfcs/rfc0001.html" quoteTitle="true" derivedAnchor="WebAPIext">
          <front>
            <title>WADG0001 WebAPI type extension</title>
            <author initials="M" surname="Ralphson" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N" surname="Evans" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="July" day="08"/>
          </front>
          <refcontent>Draft Community Group Report</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="api-catalog-example-linkset" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-example-api-catalog-documen">Example API Catalog Documents</name>
      <t indent="0" pn="section-appendix.a-1">This section is informative and provides and example of an API 
catalog document using the Linkset format.</t>
      <section anchor="api-catalog-example-rfc8615" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.1">
        <name slugifiedName="name-using-linkset-with-link-rel">Using Linkset with Link Relations Defined in RFC 8631</name>
        <t indent="0" pn="section-appendix.a.1-1">This example uses the Linkset format <xref target="RFC9264" format="default" sectionFormat="of" derivedContent="RFC9264"/> and the following
link relations defined in <xref target="RFC8631" format="default" sectionFormat="of" derivedContent="RFC8631"/>:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-appendix.a.1-2">
          <dt pn="section-appendix.a.1-2.1">"service-desc":</dt>
          <dd pn="section-appendix.a.1-2.2">Used to link to a description of the API that
   is primarily intended for machine consumption (for example, the <xref target="OAS" format="default" sectionFormat="of" derivedContent="OAS"/> specification, YAML, or JSON file).</dd>
          <dt pn="section-appendix.a.1-2.3">"service-doc":</dt>
          <dd pn="section-appendix.a.1-2.4">Used to link to API documentation that is primarily
intended for human consumption (an example of human-readable
documentation is the IETF <eref target="https://datatracker.ietf.org/api/submission" brackets="angle">Internet-Draft submission API
instructions</eref>).</dd>
          <dt pn="section-appendix.a.1-2.5">"service-meta":</dt>
          <dd pn="section-appendix.a.1-2.6">Used to link to additional metadata about the API
and is primarily intended for machine consumption.</dd>
          <dt pn="section-appendix.a.1-2.7">"status":</dt>
          <dd pn="section-appendix.a.1-2.8">Used to link to the API status (e.g., API "health"
indication) for machine and/or human consumption.</dd>
        </dl>
        <t indent="0" pn="section-appendix.a.1-3">Client request:</t>
        <sourcecode type="http-message" markers="false" pn="section-appendix.a.1-4">
GET .well-known/api-catalog HTTP/1.1
Host: example.com
Accept: application/linkset+json
</sourcecode>
        <t indent="0" pn="section-appendix.a.1-5">Server response:</t>
        <sourcecode type="http-message" markers="false" pn="section-appendix.a.1-6">
HTTP/1.1 200 OK
Date: Mon, 01 Jun 2023 00:00:01 GMT
Server: Apache-Coyote/1.1
Content-Type: application/linkset+json;
    profile="https://www.rfc-editor.org/info/rfc9727"
</sourcecode>
        <sourcecode type="ison" markers="false" pn="section-appendix.a.1-7">
{
 "linkset": [
  {
   "anchor": "https://developer.example.com/apis/foo_api",
   "service-desc": [
    {
     "href": "https://developer.example.com/apis/foo_api/spec",
     "type": "application/yaml"
    }
   ],
   "status": [
    {
     "href": "https://developer.example.com/apis/foo_api/status",
     "type": "application/json"
    }
   ],
   "service-doc": [
    {
     "href": "https://developer.example.com/apis/foo_api/doc",
     "type": "text/html"
    }
   ],
   "service-meta": [
    {
     "href": "https://developer.example.com/apis/foo_api/policies",
     "type": "text/xml"
    }
   ]
  },
  {
   "anchor": "https://developer.example.com/apis/bar_api",
   "service-desc": [
    {
     "href": "https://developer.example.com/apis/bar_api/spec",
     "type": "application/yaml"
    }
   ],
   "status": [
    {
     "href": "https://developer.example.com/apis/bar_api/status",
     "type": "application/json"
    }
   ],
   "service-doc": [
    {
     "href": "https://developer.example.com/apis/bar_api/doc",
     "type": "text/plain"
    }
   ]
  },
  {
   "anchor": "https://apis.example.net/apis/cantona_api",
   "service-desc": [
    {
     "href": "https://apis.example.net/apis/cantona_api/spec",
     "type": "text/n3"
    }
   ],
   "service-doc": [
    {
     "href": "https://apis.example.net/apis/cantona_api/doc",
     "type": "text/html"
    }
   ]
  }
 ]
}
</sourcecode>
      </section>
      <section anchor="api-catalog-example-linkset-bookmarks" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.2">
        <name slugifiedName="name-using-linkset-with-bookmark">Using Linkset with Bookmarks</name>
        <t indent="0" pn="section-appendix.a.2-1">This example also uses the Linkset format <xref target="RFC9264" format="default" sectionFormat="of" derivedContent="RFC9264"/> and lists the 
API endpoints in an array of bookmarks. Each link shares the same 
context anchor (the well-known URI of the API catalog) and "item" 
<xref target="RFC9264" format="default" sectionFormat="of" derivedContent="RFC9264"/> link relation (to indicate they are an item in the 
catalog). The intent is that by following a bookmark link, a 
machine client can discover the purpose and usage policy for each 
API; hence, the document targeted by the bookmark link should support 
this.</t>
        <t indent="0" pn="section-appendix.a.2-2">Client request:</t>
        <sourcecode type="http-message" markers="false" pn="section-appendix.a.2-3">
GET .well-known/api-catalog HTTP/1.1
Host: example.com
Accept: application/linkset+json
</sourcecode>
        <t indent="0" pn="section-appendix.a.2-4">Server response:</t>
        <sourcecode type="http-message" markers="false" pn="section-appendix.a.2-5">
HTTP/1.1 200 OK
Date: Mon, 01 Jun 2023 00:00:01 GMT
Server: Apache-Coyote/1.1
Content-Type: application/linkset+json;
    profile="https://www.rfc-editor.org/info/rfc9727"
</sourcecode>
        <sourcecode type="json" markers="false" pn="section-appendix.a.2-6">
{ "linkset":
 [
   { "anchor": "https://www.example.com/.well-known/api-catalog",
     "item": [
       {"href": "https://developer.example.com/apis/foo_api"},
       {"href": "https://developer.example.com/apis/bar_api"},
       {"href": "https://developer.example.com/apis/cantona_api"}
     ]
   }
 ]
}
</sourcecode>
      </section>
      <section anchor="api-catalog-other-formats" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.3">
        <name slugifiedName="name-other-api-catalog-formats">Other API Catalog Formats</name>
        <t indent="0" pn="section-appendix.a.3-1">A non-exhaustive list of other API catalog document formats includes:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-2">
          <li pn="section-appendix.a.3-2.1">
            <t indent="0" pn="section-appendix.a.3-2.1.1">An APIs.json document <xref target="APIsjson" format="default" sectionFormat="of" derivedContent="APIsjson"/>.</t>
          </li>
          <li pn="section-appendix.a.3-2.2">
            <t indent="0" pn="section-appendix.a.3-2.2.1">A RESTDesc semantic description for hypermedia APIs <xref target="RESTdesc" format="default" sectionFormat="of" derivedContent="RESTdesc"/>.</t>
          </li>
          <li pn="section-appendix.a.3-2.3">
            <t indent="0" pn="section-appendix.a.3-2.3.1">A Hypertext Application Language document <xref target="I-D.kelly-json-hal" format="default" sectionFormat="of" derivedContent="HAL"/>.</t>
          </li>
          <li pn="section-appendix.a.3-2.4">
            <t indent="0" pn="section-appendix.a.3-2.4.1">An extension to the Schema.org WebAPI type <xref target="WebAPIext" format="default" sectionFormat="of" derivedContent="WebAPIext"/>.</t>
          </li>
        </ul>
      </section>
      <section anchor="api-catalog-example-linkset-nesting" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.4">
        <name slugifiedName="name-nesting-api-catalog-links-2">Nesting API Catalog Links</name>
        <t indent="0" pn="section-appendix.a.4-1">In this example, a request to the /.well-known/api-catalog URI
returns an array of links of relation type "api-catalog". This can be
useful to Publishers with a large number of APIs who wish to group
them in smaller catalogs (as described in <xref target="scalability" format="default" sectionFormat="of" derivedContent="Section 5.3"/>).</t>
        <t indent="0" pn="section-appendix.a.4-2">Client request:</t>
        <sourcecode type="http-message" markers="false" pn="section-appendix.a.4-3">
GET .well-known/api-catalog HTTP/1.1
Host: example.com
Accept: application/linkset+json
</sourcecode>
        <t indent="0" pn="section-appendix.a.4-4">Server response:</t>
        <sourcecode type="http-message" markers="false" pn="section-appendix.a.4-5">
HTTP/1.1 200 OK
Date: Mon, 01 Jun 2023 00:00:01 GMT
Server: Apache-Coyote/1.1
Content-Type: application/linkset+json;
    profile="https://www.rfc-editor.org/info/rfc9727"
</sourcecode>
        <sourcecode type="json" markers="false" pn="section-appendix.a.4-6">
{
  "linkset": [
    {
      "anchor": "https://www.example.com/.well-known/api-catalog",
      "api-catalog": [
        {
          "href": "https://apis.example.com/iot/api-catalog"
        },
        {
          "href": "https://ecommerce.example.com/api-catalog"
        },
        {
          "href": "https://developer.example.com/gaming/api-catalog"
        }
      ]
    }
  ]
}
</sourcecode>
      </section>
    </section>
    <section anchor="acknowledgements" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.b-1">Thanks to <contact fullname="Jan Algermissen"/>, <contact fullname="Phil Archer"/>, <contact fullname="Tim Bray"/>, <contact fullname="Ben Bucksch"/>, <contact fullname="Sanjay Dalal"/>, <contact fullname="David Dong"/>, <contact fullname="Erik Kline"/>, <contact fullname="Mallory Knodel"/>, <contact fullname="Murray Kucherawy"/>,
      <contact fullname="Max Maton"/>, <contact fullname="Darrel Miller"/>,
      <contact fullname="Mark Nottingham"/>, <contact fullname="Roberto       Polli"/>, <contact fullname="Joey Salazar"/>, <contact fullname="Rich       Salz"/>, <contact fullname="Herbert Van De Sompel"/>, <contact fullname="Orie Steele"/>, <contact fullname="Tina Tsou"/>, <contact fullname="Gunter Van de Velde"/>, <contact fullname="Éric Vyncke"/>,
      and <contact fullname="Erik Wilde"/> for their reviews, suggestions, and
      support.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author initials="K." surname="Smith" fullname="Kevin Smith">
        <organization showOnFrontPage="true">Vodafone</organization>
        <address>
          <email>kevin.smith@vodafone.com</email>
          <uri>https://www.vodafone.com</uri>
        </address>
      </author>
    </section>
  </back>
</rfc>
