doc: update references to RFCs using :rfc: role across multiple files

kartben · kartben · commit 76657ab128be · 2025-11-25T12:58:14.000+01:00
Sphinx has a built-in `:rfc:` role for referencing RFC documents.
This commit updates documentation pages referencing RFCs to use this role.

Signed-off-by: Benjamin Cabé &lt;benjamin@zephyrproject.org&gt;
diff --git a/doc/build/dts/api-usage.rst b/doc/build/dts/api-usage.rst
@@ -391,11 +391,8 @@ useful to understand them since they will frequently be seen in compiler error
 messages.
 
 This section contains an Augmented Backus-Naur Form grammar for these
-generated macros, with examples and more details in comments. See `RFC 7405`_
-(which extends `RFC 5234`_) for a syntax specification.
+generated macros, with examples and more details in comments. See :rfc:`7405`
+(which extends :rfc:`5234`) for a syntax specification.
 
 .. literalinclude:: macros.bnf
    :language: abnf
-
-.. _RFC 7405: https://tools.ietf.org/html/rfc7405
-.. _RFC 5234: https://tools.ietf.org/html/rfc5234
diff --git a/doc/connectivity/networking/api/coap.rst b/doc/connectivity/networking/api/coap.rst
@@ -14,7 +14,7 @@ The Constrained Application Protocol (CoAP) is a specialized web transfer
 protocol for use with constrained nodes and constrained (e.g., low-power,
 lossy) networks. It provides a convenient API for RESTful Web services
 that support CoAP's features. For more information about the protocol
-itself, see `IETF RFC7252 The Constrained Application Protocol <https://tools.ietf.org/html/rfc7252>`_.
+itself, see :rfc:`7252`.
 
 Zephyr provides a CoAP library which supports client and server roles.
 The library can be enabled with :kconfig:option:`CONFIG_COAP` Kconfig option and
@@ -29,10 +29,10 @@ See :ref:`lwm2m_interface` for more information.
 
 Supported RFCs:
 
-- `RFC7252: The Constrained Application Protocol (CoAP) <https://tools.ietf.org/html/rfc7252>`_
-- `RFC6690: Constrained RESTful Environments (CoRE) Link Format <https://tools.ietf.org/html/rfc6690>`_
-- `RFC7959: Block-Wise Transfers in the Constrained Application Protocol (CoAP) <https://tools.ietf.org/html/rfc7959>`_
-- `RFC7641: Observing Resources in the Constrained Application Protocol (CoAP) <https://tools.ietf.org/html/rfc7641>`_
+- :rfc:`7252` - The Constrained Application Protocol (CoAP)
+- :rfc:`6690` - Constrained RESTful Environments (CoRE) Link Format
+- :rfc:`7959` - Block-Wise Transfers in the Constrained Application Protocol (CoAP)
+- :rfc:`7641` - Observing Resources in the Constrained Application Protocol (CoAP)
 
 .. note:: Not all parts of these RFCs are supported. Features are supported based on Zephyr requirements.
 
diff --git a/doc/connectivity/networking/api/coap_client.rst b/doc/connectivity/networking/api/coap_client.rst
@@ -81,7 +81,7 @@ The following is an example of a very simple response handling function:
 CoAP options may also be added to the request by the application. The following is an example of
 the application adding a Block2 option to the initial request, to suggest a maximum block size to
 the server for a resource that it expects to be large enough to require a blockwise transfer (see
-RFC7959 Figure 3: Block-Wise GET with Early Negotiation).
+:rfc:`7959` Figure 3: Block-Wise GET with Early Negotiation).
 
 .. code-block:: c
 
diff --git a/doc/connectivity/networking/api/dns_resolve.rst b/doc/connectivity/networking/api/dns_resolve.rst
@@ -10,8 +10,7 @@ DNS Resolve
 Overview
 ********
 
-The DNS resolver implements a basic DNS resolver according
-to `IETF RFC1035 on Domain Implementation and Specification <https://tools.ietf.org/html/rfc1035>`_.
+The DNS resolver implements a basic DNS resolver according to :rfc:`1035`.
 Supported DNS answers are IPv4/IPv6 addresses and CNAME.
 
 If a CNAME is received, the DNS resolver will create another DNS query.
@@ -20,20 +19,17 @@ The number of additional queries is controlled by the
 
 The multicast DNS (mDNS) client resolver support can be enabled by setting
 :kconfig:option:`CONFIG_MDNS_RESOLVER` Kconfig option.
-See `IETF RFC6762 <https://tools.ietf.org/html/rfc6762>`_ for more details
-about mDNS.
+See :rfc:`6762` for more details about mDNS.
 
 The link-local multicast name resolution (LLMNR) client resolver support can be
 enabled by setting the :kconfig:option:`CONFIG_LLMNR_RESOLVER` Kconfig variable.
-See `IETF RFC4795 <https://tools.ietf.org/html/rfc4795>`_ for more details
-about LLMNR.
+See :rfc:`4795` for more details about LLMNR.
 
 For more information about DNS configuration variables, see:
 :zephyr_file:`subsys/net/lib/dns/Kconfig`. The DNS resolver API can be found at
 :zephyr_file:`include/zephyr/net/dns_resolve.h`.
 
-DNS-based service discovery queries described in
-`IETF RFC6763 <https://datatracker.ietf.org/doc/html/rfc6763>`_
+DNS-based service discovery queries described in :rfc:`6763`
 can be done by :c:func:`dns_resolve_service` API.
 The returned service descriptions are passed to user supplied callback
 and the API sets the address family to :c:macro:`AF_LOCAL` to indicate that
diff --git a/doc/connectivity/networking/api/ppp.rst b/doc/connectivity/networking/api/ppp.rst
@@ -25,13 +25,13 @@ PPP support must be enabled at compile time by setting option
 The PPP implementation supports only these protocols:
 
 * LCP (Link Control Protocol,
-  `RFC1661 <https://tools.ietf.org/html/rfc1661>`__)
+  :rfc:`1661`)
 * HDLC (High-level data link control,
-  `RFC1662 <https://tools.ietf.org/html/rfc1662>`__)
+  :rfc:`1662`)
 * IPCP (IP Control Protocol,
-  `RFC1332 <https://tools.ietf.org/html/rfc1332>`__)
+  :rfc:`1332`)
 * IPV6CP (IPv6 Control Protocol,
-  `RFC5072 <https://tools.ietf.org/html/rfc5072>`__)
+  :rfc:`5072`)
 
 For using PPP with a cellular modem, see :zephyr:code-sample:`cellular-modem` sample
 for additional information.
diff --git a/doc/connectivity/networking/api/sntp.rst b/doc/connectivity/networking/api/sntp.rst
@@ -10,8 +10,7 @@ Simple Network Time Protocol Library
 Overview
 ********
 
-The SNTP library implements
-`IETF RFC4330 (Simple Network Time Protocol v4) <https://tools.ietf.org/html/rfc4330>`_.
+The SNTP library implements :rfc:`4330`.
 
 SNTP provides a way to synchronize clocks in computer networks.
 
diff --git a/doc/connectivity/networking/api/socks5.rst b/doc/connectivity/networking/api/socks5.rst
@@ -17,8 +17,7 @@ See this
 `SOCKS5 Wikipedia article <https://en.wikipedia.org/wiki/SOCKS#SOCKS5>`_
 for a detailed overview of how SOCKS5 works.
 
-For more information about the protocol itself, see
-`IETF RFC1928 SOCKS Protocol Version 5 <https://tools.ietf.org/html/rfc1928>`_.
+For more information about the protocol itself, see :rfc:`1928`.
 
 SOCKS5 API
 **********
diff --git a/doc/connectivity/networking/api/trickle.rst b/doc/connectivity/networking/api/trickle.rst
@@ -10,8 +10,7 @@ Trickle Timer Library
 Overview
 ********
 
-The Trickle timer library implements
-`IETF RFC6206 (Trickle Algorithm) <https://tools.ietf.org/html/rfc6206>`_.
+The Trickle timer library implements :rfc:`6206`.
 
 The Trickle algorithm allows nodes in a lossy shared medium (e.g.,
 low-power and lossy networks) to exchange information in a highly
diff --git a/doc/connectivity/networking/api/websocket.rst b/doc/connectivity/networking/api/websocket.rst
@@ -19,8 +19,7 @@ See this
 `Websocket Wikipedia article <https://en.wikipedia.org/wiki/WebSocket>`_
 for a detailed overview of how Websocket works.
 
-For more information about the protocol itself, see
-`IETF RFC6455 The WebSocket Protocol <https://tools.ietf.org/html/rfc6455>`_.
+For more information about the protocol itself, see :rfc:`6455`.
 
 Websocket Transport
 *******************
diff --git a/doc/connectivity/networking/net-stack-architecture.rst b/doc/connectivity/networking/net-stack-architecture.rst
@@ -57,12 +57,14 @@ The network stack is layered and consists of the following parts:
 * **L2 Network Technologies.** This provides a common API for sending and
   receiving data to and from an actual network device.
   See :ref:`L2 overview <net_l2_interface>` for more details.
+
   These network technologies include :ref:`Ethernet <ethernet_interface>`,
   :ref:`IEEE 802.15.4 <ieee802154_interface>`,
   :ref:`Bluetooth <bluetooth_api>`, :ref:`CANBUS <can_api>`, etc.
+  
   Some of these technologies support IPv6 header compression (6Lo),
-  see `RFC 6282 <https://tools.ietf.org/html/rfc6282>`_ for details.
-  For example `ARP <https://tools.ietf.org/html/rfc826>`_ for IPv4 is done by
+  see :rfc:`6282` for details.
+  For example ARP (:rfc:`826`) for IPv4 is done by
   the :ref:`Ethernet component <ethernet_interface>`.
 
 * **Network Device Drivers.** The actual low-level device drivers handle the
diff --git a/doc/connectivity/networking/overview.rst b/doc/connectivity/networking/overview.rst
@@ -21,40 +21,38 @@ can be disabled if not needed.
   * Developer can set the number of unicast and multicast IPv6 addresses that
     are active at the same time.
   * The IPv6 address for the device can be set either statically or
-    dynamically using SLAAC (Stateless Address Auto Configuration)
-    (`RFC 4862 <https://tools.ietf.org/html/rfc4862>`_).
+    dynamically using SLAAC (Stateless Address Auto Configuration, :rfc:`4862`).
   * The system also supports multiple IPv6 prefixes and the maximum
     IPv6 prefix count can be configured at build time.
   * The IPv6 neighbor cache can be disabled if not needed, and its size can be
     configured at build time.
   * The IPv6 neighbor discovery support
-    (`RFC 4861 <https://tools.ietf.org/html/rfc4861>`_) is enabled by default.
+    (:rfc:`4861`) is enabled by default.
   * Multicast Listener Discovery v2 support
-    (`RFC 3810 <https://tools.ietf.org/html/rfc3810>`_) is enabled by default.
+    (:rfc:`3810`) is enabled by default.
   * IPv6 header compression (6lo) is available for IPv6 connectivity for
-    IEEE 802.15.4 networks (`RFC 4944 <https://tools.ietf.org/html/rfc4944>`_).
+    IEEE 802.15.4 networks (:rfc:`4944`).
 
 * **IPv4** The legacy IPv4 is supported by the networking stack. It
   cannot be used by IEEE 802.15.4 as this network technology supports
   only IPv6. IPv4 can be used in Ethernet based networks. By default
   IPv4 support is disabled.
 
   * DHCP (Dynamic Host Configuration Protocol) client is supported
-    (`RFC 2131 <https://tools.ietf.org/html/rfc2131>`_).
+    (:rfc:`2131`).
   * The IPv4 address can also be configured manually. Static IPv4 addresses
     are supported by default.
 
 * **Dual stack support.** The networking stack allows a developer to configure
   the system to use both IPv6 and IPv4 at the same time.
 
-* **UDP** User Datagram Protocol
-  (`RFC 768 <https://tools.ietf.org/html/rfc768>`_) is supported.
+* **UDP** User Datagram Protocol (:rfc:`768`) is supported.
   The developer can send UDP datagrams (client side support) or create a
   listener to receive UDP packets destined to certain port (server side
   support).
 
-* **TCP** Transmission Control Protocol
-  (`RFC 793 <https://tools.ietf.org/html/rfc793>`_) is supported. Both server
+* **TCP** Transmission Control Protocol (:rfc:`793`) is supported. Both server
+  (:rfc:`793`) is supported. Both server
   and client roles can be used the application. The amount of TCP sockets
   that are available to applications can be configured at build time.
 
@@ -71,8 +69,7 @@ can be disabled if not needed.
   A sample :zephyr:code-sample:`mqtt-publisher` client application for MQTT v3.1.1 is
   implemented.
 
-* **CoAP** Constrained Application Protocol
-  (`RFC 7252 <https://tools.ietf.org/html/rfc7252>`_) is supported.
+* **CoAP** Constrained Application Protocol (:rfc:`7252`) is supported.
   Both :zephyr:code-sample:`coap-client` and :zephyr:code-sample:`coap-server` sample
   applications are implemented.
 
@@ -85,21 +82,20 @@ can be disabled if not needed.
   :zephyr:code-sample:`lwm2m-client` sample implements the library as an example.
 
 * **HTTP** Hypertext Transfer Protocol client and server are supported.
-  :ref:`http_client_interface` library supports HTTP/1.1 (`RFC 2616`_).
-  :ref:`http_server_interface` library supports HTTP/1.1 (`RFC 2616`_) and
-  HTTP/2 (`RFC 9113`_).
+  :ref:`http_client_interface` library supports HTTP/1.1 (:rfc:`2616`).
+  :ref:`http_server_interface` library supports HTTP/1.1 (:rfc:`2616`) and
+  HTTP/2 (:rfc:`9113`).
   :zephyr:code-sample:`sockets-http-client` and
   :zephyr:code-sample:`sockets-http-server` samples are provided.
 
 * **DNS** Domain Name Service
-  (`RFC 1035 <https://tools.ietf.org/html/rfc1035>`_) client functionality
+  (:rfc:`1035`) client functionality
   is supported.
   Applications can use the DNS API to query domain name information or IP
   addresses from the DNS server. Both IPv4 (A) and IPv6 (AAAA) records can
   be queried.
-  Both multicast DNS (mDNS) (`RFC 6762 <https://tools.ietf.org/html/rfc6762>`_)
-  and link-local multicast name resolution
-  (LLMNR) (`RFC 4795 <https://tools.ietf.org/html/rfc4795>`_) are supported.
+  Both multicast DNS (mDNS) (:rfc:`6762`) and link-local multicast name resolution
+  (LLMNR, :rfc:`4795`) are supported.
 
 * **Network Management API.** Applications can use network management API to
   listen management events generated by core stack when for example IP address
@@ -184,9 +180,3 @@ The networking stack source code tree is organized as follows:
 
 .. _LwM2M specification 1.1.1:
    https://www.openmobilealliance.org/release/LightweightM2M/V1_1_1-20190617-A/
-
-.. _RFC 2616:
-   https://tools.ietf.org/html/rfc2616
-
-.. _RFC 9113:
-   https://tools.ietf.org/html/rfc9113
diff --git a/doc/kernel/timeutil.rst b/doc/kernel/timeutil.rst
@@ -45,8 +45,7 @@ Time scale instants can be represented in multiple ways including:
 
 * Seconds since an epoch. POSIX representations of time in this form include
   ``time_t`` and ``struct timespec``, which are generally interpreted as a
-  representation of `"UNIX Time"
-  <https://tools.ietf.org/html/rfc8536#section-2>`__.
+  representation of "UNIX Time" (see :rfc:`8536#section-2`).
 
 * Calendar time as a year, month, day, hour, minutes, and seconds relative to
   an epoch. POSIX representations of time in this form include ``struct tm``.
@@ -250,17 +249,15 @@ influenced by longitude, but the offset may be adjusted ("daylight
 saving time") to align standard time to the local solar time. In a sense
 local time is "more discontinuous" than UT.
 
-`POSIX Time <https://tools.ietf.org/html/rfc8536#section-2>`__ is a time scale
-that counts seconds since the "POSIX epoch" at 1970-01-01T00:00:00Z (i.e. the
-start of 1970 UTC). `UNIX Time
-<https://tools.ietf.org/html/rfc8536#section-2>`__ is an extension of POSIX
+POSIX Time (see :rfc:`8536#section-2`) is a time scale
+that counts seconds since the "POSIX epoch" at 1970-01-01T00:00:00Z (i.e. the
+start of 1970 UTC). UNIX Time is an extension of POSIX
 time using negative values to represent times before the POSIX epoch. Both of
 these scales assume that every day has exactly 86400 seconds. In normal use
 instants in these scales correspond to times in the UTC scale, so they inherit
 the discontinuity.
 
-The continuous analogue is `UNIX Leap Time
-<https://tools.ietf.org/html/rfc8536#section-2>`__ which is UNIX time plus all
+The continuous analogue is UNIX Leap Time which is UNIX time plus all
 leap-second corrections added after the POSIX epoch (when TAI-UTC was 8 s).
 
 Example of Time Scale Differences
diff --git a/doc/security/sensor-threat.rst b/doc/security/sensor-threat.rst
@@ -224,8 +224,8 @@ where data or assets are communicated between entities of the system.
 
       i.   **Naming**. The certificate shall name the host and service
            the cloud service server is providing.
-           `RFC6125 <https://tools.ietf.org/html/rfc6125>`__ describes
-           best practices for this. It is permissible for the device to
+           :rfc:`6125` describes best practices for this.
+           It is permissible for the device to
            require the certificate to be more restrictive than as
            described in this RFC, provided the service can use a
            certificate that can comply.
@@ -234,8 +234,8 @@ where data or assets are communicated between entities of the system.
            certificate chain has a valid signature path from a root
            certificate contained within the device, to the certificate
            presented by the service.
-           `RFC4158 <https://tools.ietf.org/html/rfc4158>`__ describes
-           this is general. The device is permitted to require a more
+           :rfc:`4158` describes this in general.
+           The device is permitted to require a more
            restricted path, provided the server certificate used
            complies with this restriction.
 
@@ -263,8 +263,7 @@ where data or assets are communicated between entities of the system.
           client to authenticate itself using the *password* field of
           the MQTT CONNECT packet. However, the secret itself must not
           be transmitted in this packet. Instead, a token-based
-          protocol, such as
-          `RFC7519 <https://tools.ietf.org/html/rfc7519>`__\ 's JSON Web
+          protocol, such as :rfc:`7519`'s JSON Web
           Token (JWT) can be used. These tokens will generally have a
           small validity period (e.g. 1 hour), to prevent them from
           being reused if they are intercepted. The token shall not be
@@ -284,9 +283,9 @@ where data or assets are communicated between entities of the system.
    contain hardware that maintains a secure time. However, most SoCs in
    use do not have support for this, and it will be necessary to consult
    an external time service.
-   `RFC4330 <https://tools.ietf.org/html/rfc4330>`__ and referenced RFCs
-   describe the Simple Network Time Protocol that can be used to query
-   the current time from a network time server.
+   :rfc:`4330` and referenced RFCs describe the Simple Network Time
+   Protocol that can be used to query the current time from a network time
+   server.
 
 5. **Device lifecycle**. An IoT device will have a lifecycle from
    production to destruction and disposal of the device. Aspects of this
diff --git a/doc/services/misc.rst b/doc/services/misc.rst
@@ -27,8 +27,7 @@ JSON
 JWT
 ===
 
-JSON Web Tokens (JWT) are an open, industry standard [RFC
-7519](https://tools.ietf.org/html/rfc7519) method for representing
+JSON Web Tokens (JWT) are an open, industry standard (:rfc:`7519`) method for representing
 claims securely between two parties.  Although JWT is fairly flexible,
 this API is limited to creating the simplistic tokens needed to
 authenticate with the Google Core IoT infrastructure.
@@ -42,8 +41,7 @@ UUID
 ====
 
 Universally Unique Identifiers (UUID), also known as Globally Unique
-IDentifiers (GUIDs) are an open, industry standard [RFC
-9562](https://tools.ietf.org/html/rfc9562) 128 bits long identifiers
+IDentifiers (GUIDs) are an open, industry standard (:rfc:`9562`) 128 bits long identifiers
 intended to guarantee uniqueness across space and time.
 
 .. doxygengroup:: uuid
diff --git a/doc/services/tfm/overview.rst b/doc/services/tfm/overview.rst
@@ -252,7 +252,7 @@ protected in secure devices, and inaccessible directly by users.
 
 ``TFM_CRYPTO_ALG_HUK_DERIVATION`` identifies the default key derivation
 algorithm used if a software implementation is used. The current default
-algorithm is ``HKDF`` (RFC 5869) with a SHA-256 hash. Other hardware
+algorithm is ``HKDF`` (:rfc:`5869`) with a SHA-256 hash. Other hardware
 implementations may be available on some platforms.
 
 Non-Secure Processing Environment
diff --git a/samples/net/syslog_net/README.rst b/samples/net/syslog_net/README.rst
@@ -9,8 +9,7 @@ Overview
 
 This sample application enables a remote syslog service that will
 send syslog messages to a remote server, as configured in ``prj.conf``.
-See https://tools.ietf.org/html/rfc5424 and https://tools.ietf.org/html/rfc5426
-for more details about syslog protocol over UDP.
+See :rfc:`5424` and :rfc:`5426` for more details about syslog protocol over UDP.
 
 The source code for this sample application can be found at:
 :zephyr_file:`samples/net/syslog_net`.
diff --git a/samples/subsys/uuid/README.rst b/samples/subsys/uuid/README.rst
@@ -7,7 +7,7 @@ Overview
 ********
 
 This sample app demonstrates the use of the :c:group:`uuid` utilities to generate and manipulate
-UUIDs accordingly to IETF RFC 9562.
+UUIDs accordingly to :rfc:`9562`.
 
 The following functionality is demonstrated:
 
