diff --git a/Doc/library/binascii.rst b/Doc/library/binascii.rst
index 4d3d0e0..a4efef8 100644
--- a/Doc/library/binascii.rst
+++ b/Doc/library/binascii.rst
@@ -80,7 +80,7 @@
    *quotetabs* is present and true, all tabs and spaces will be encoded.   If the
    optional argument *istext* is present and true, newlines are not encoded but
    trailing whitespace will be encoded. If the optional argument *header* is
-   present and true, spaces will be encoded as underscores per RFC1522. If the
+   present and true, spaces will be encoded as underscores per :rfc:`1522`. If the
    optional argument *header* is present and false, newline characters will be
    encoded as well; otherwise linefeed conversion might corrupt the binary data
    stream.
diff --git a/Doc/library/codecs.rst b/Doc/library/codecs.rst
index 74b24e1..24008a0 100644
--- a/Doc/library/codecs.rst
+++ b/Doc/library/codecs.rst
@@ -1425,7 +1425,7 @@
 
 Python supports this conversion in several ways:  the ``idna`` codec performs
 conversion between Unicode and ACE, separating an input string into labels
-based on the separator characters defined in `section 3.1`_ (1) of :rfc:`3490`
+based on the separator characters defined in :rfc:`section 3.1 of RFC 3490 <3490#section-3.1>`
 and converting each label to ACE as required, and conversely separating an input
 byte string into labels based on the ``.`` separator and converting any ACE
 labels found into unicode.  Furthermore, the :mod:`socket` module
@@ -1436,8 +1436,6 @@
 names (:mod:`http.client` then also transparently sends an IDNA hostname in the
 :mailheader:`Host` field if it sends that field at all).
 
-.. _section 3.1: https://tools.ietf.org/html/rfc3490#section-3.1
-
 When receiving host names from the wire (such as in reverse name lookup), no
 automatic conversion to Unicode is performed: Applications wishing to present
 such host names to the user should decode them to Unicode.
diff --git a/Doc/library/email.examples.rst b/Doc/library/email.examples.rst
index 84e9aee..fc96462 100644
--- a/Doc/library/email.examples.rst
+++ b/Doc/library/email.examples.rst
@@ -12,7 +12,7 @@
 .. literalinclude:: ../includes/email-simple.py
 
 
-Parsing RFC822 headers can easily be done by the using the classes
+Parsing :rfc:`822` headers can easily be done by the using the classes
 from the :mod:`~email.parser` module:
 
 .. literalinclude:: ../includes/email-headers.py
diff --git a/Doc/library/ftplib.rst b/Doc/library/ftplib.rst
index 7291dfe8..6c39f9a 100644
--- a/Doc/library/ftplib.rst
+++ b/Doc/library/ftplib.rst
@@ -295,7 +295,7 @@
    If optional *rest* is given, a ``REST`` command is sent to the server, passing
    *rest* as an argument.  *rest* is usually a byte offset into the requested file,
    telling the server to restart sending the file's bytes at the requested offset,
-   skipping over the initial bytes.  Note however that RFC 959 requires only that
+   skipping over the initial bytes.  Note however that :rfc:`959` requires only that
    *rest* be a string containing characters in the printable range from ASCII code
    33 to ASCII code 126.  The :meth:`transfercmd` method, therefore, converts
    *rest* to a string, but no check is performed on the string's contents.  If the
diff --git a/Doc/library/hashlib.rst b/Doc/library/hashlib.rst
index eda18ad..0ed0482 100644
--- a/Doc/library/hashlib.rst
+++ b/Doc/library/hashlib.rst
@@ -283,7 +283,7 @@
 .. index::
    single: blake2b, blake2s
 
-BLAKE2_ is a cryptographic hash function defined in RFC-7693_ that comes in two
+BLAKE2_ is a cryptographic hash function defined in :rfc:`7693` that comes in two
 flavors:
 
 * **BLAKE2b**, optimized for 64-bit platforms and produces digests of any size
@@ -707,7 +707,6 @@
 
 * *Alexandr Sokolovskiy*
 
-.. _RFC-7693: https://tools.ietf.org/html/rfc7693
 .. _BLAKE2: https://blake2.net
 .. _HMAC: https://en.wikipedia.org/wiki/Hash-based_message_authentication_code
 .. _BLAKE: https://131002.net/blake/
diff --git a/Doc/library/http.cookiejar.rst b/Doc/library/http.cookiejar.rst
index 5370601..d8da668 100644
--- a/Doc/library/http.cookiejar.rst
+++ b/Doc/library/http.cookiejar.rst
@@ -88,7 +88,7 @@
    :class:`DefaultCookiePolicy` objects.
 
    :class:`DefaultCookiePolicy` implements the standard accept / reject rules for
-   Netscape and RFC 2965 cookies.  By default, RFC 2109 cookies (ie. cookies
+   Netscape and :rfc:`2965` cookies.  By default, :rfc:`2109` cookies (ie. cookies
    received in a :mailheader:`Set-Cookie` header with a version cookie-attribute of
    1) are treated according to the RFC 2965 rules.  However, if RFC 2965 handling
    is turned off or :attr:`rfc2109_as_netscape` is ``True``, RFC 2109 cookies are
@@ -100,7 +100,7 @@
 
 .. class:: Cookie()
 
-   This class represents Netscape, RFC 2109 and RFC 2965 cookies.  It is not
+   This class represents Netscape, :rfc:`2109` and :rfc:`2965` cookies.  It is not
    expected that users of :mod:`http.cookiejar` construct their own :class:`Cookie`
    instances.  Instead, if necessary, call :meth:`make_cookies` on a
    :class:`CookieJar` instance.
@@ -123,14 +123,14 @@
       the one sketched out in ``cookie_spec.html``.
 
    :rfc:`2109` - HTTP State Management Mechanism
-      Obsoleted by RFC 2965. Uses :mailheader:`Set-Cookie` with version=1.
+      Obsoleted by :rfc:`2965`. Uses :mailheader:`Set-Cookie` with version=1.
 
    :rfc:`2965` - HTTP State Management Mechanism
       The Netscape protocol with the bugs fixed.  Uses :mailheader:`Set-Cookie2` in
       place of :mailheader:`Set-Cookie`.  Not widely used.
 
    http://kristol.org/cookie/errata.html
-      Unfinished errata to RFC 2965.
+      Unfinished errata to :rfc:`2965`.
 
    :rfc:`2964` - Use of HTTP State Management
 
@@ -320,7 +320,7 @@
 
    .. note::
 
-      This loses information about RFC 2965 cookies, and also about newer or
+      This loses information about :rfc:`2965` cookies, and also about newer or
       non-standard cookie-attributes such as ``port``.
 
    .. warning::
@@ -410,13 +410,13 @@
 
 .. attribute:: CookiePolicy.rfc2965
 
-   Implement RFC 2965 protocol.
+   Implement :rfc:`2965` protocol.
 
 
 .. attribute:: CookiePolicy.hide_cookie2
 
    Don't add :mailheader:`Cookie2` header to requests (the presence of this header
-   indicates to the server that we understand RFC 2965 cookies).
+   indicates to the server that we understand :rfc:`2965` cookies).
 
 The most useful way to define a :class:`CookiePolicy` class is by subclassing
 from :class:`DefaultCookiePolicy` and overriding some or all of the methods
@@ -431,7 +431,7 @@
 
 Implements the standard rules for accepting and returning cookies.
 
-Both RFC 2965 and Netscape cookies are covered.  RFC 2965 handling is switched
+Both :rfc:`2965` and Netscape cookies are covered.  RFC 2965 handling is switched
 off by default.
 
 The easiest way to provide your own policy is to override this class and call
@@ -510,11 +510,11 @@
 
 .. attribute:: DefaultCookiePolicy.rfc2109_as_netscape
 
-   If true, request that the :class:`CookieJar` instance downgrade RFC 2109 cookies
+   If true, request that the :class:`CookieJar` instance downgrade :rfc:`2109` cookies
    (ie. cookies received in a :mailheader:`Set-Cookie` header with a version
    cookie-attribute of 1) to Netscape cookies by setting the version attribute of
    the :class:`Cookie` instance to 0.  The default value is :const:`None`, in which
-   case RFC 2109 cookies are downgraded if and only if RFC 2965 handling is turned
+   case RFC 2109 cookies are downgraded if and only if :rfc:`2965` handling is turned
    off.  Therefore, RFC 2109 cookies are downgraded by default.
 
 
@@ -527,11 +527,11 @@
    and isn't guaranteed to work!
 
 
-RFC 2965 protocol strictness switches:
+:rfc:`2965` protocol strictness switches:
 
 .. attribute:: DefaultCookiePolicy.strict_rfc2965_unverifiable
 
-   Follow RFC 2965 rules on unverifiable transactions (usually, an unverifiable
+   Follow :rfc:`2965` rules on unverifiable transactions (usually, an unverifiable
    transaction is one resulting from a redirect or a request for an image hosted on
    another site).  If this is false, cookies are *never* blocked on the basis of
    verifiability
@@ -541,7 +541,7 @@
 
 .. attribute:: DefaultCookiePolicy.strict_ns_unverifiable
 
-   Apply RFC 2965 rules on unverifiable transactions even to Netscape cookies.
+   Apply :rfc:`2965` rules on unverifiable transactions even to Netscape cookies.
 
 
 .. attribute:: DefaultCookiePolicy.strict_ns_domain
@@ -581,7 +581,7 @@
 
 .. attribute:: DefaultCookiePolicy.DomainRFC2965Match
 
-   When setting cookies, require a full RFC 2965 domain-match.
+   When setting cookies, require a full :rfc:`2965` domain-match.
 
 The following attributes are provided for convenience, and are the most useful
 combinations of the above flags:
@@ -605,7 +605,7 @@
 standard cookie-attributes specified in the various cookie standards.  The
 correspondence is not one-to-one, because there are complicated rules for
 assigning default values, because the ``max-age`` and ``expires``
-cookie-attributes contain equivalent information, and because RFC 2109 cookies
+cookie-attributes contain equivalent information, and because :rfc:`2109` cookies
 may be 'downgraded' by :mod:`http.cookiejar` from version 1 to version 0 (Netscape)
 cookies.
 
@@ -616,8 +616,8 @@
 
 .. attribute:: Cookie.version
 
-   Integer or :const:`None`.  Netscape cookies have :attr:`version` 0. RFC 2965 and
-   RFC 2109 cookies have a ``version`` cookie-attribute of 1.  However, note that
+   Integer or :const:`None`.  Netscape cookies have :attr:`version` 0. :rfc:`2965` and
+   :rfc:`2109` cookies have a ``version`` cookie-attribute of 1.  However, note that
    :mod:`http.cookiejar` may 'downgrade' RFC 2109 cookies to Netscape cookies, in which
    case :attr:`version` is 0.
 
@@ -673,7 +673,7 @@
 
 .. attribute:: Cookie.rfc2109
 
-   ``True`` if this cookie was received as an RFC 2109 cookie (ie. the cookie
+   ``True`` if this cookie was received as an :rfc:`2109` cookie (ie. the cookie
    arrived in a :mailheader:`Set-Cookie` header, and the value of the Version
    cookie-attribute in that header was 1).  This attribute is provided because
    :mod:`http.cookiejar` may 'downgrade' RFC 2109 cookies to Netscape cookies, in
@@ -745,7 +745,7 @@
    r = opener.open("http://example.com/")
 
 The next example illustrates the use of :class:`DefaultCookiePolicy`. Turn on
-RFC 2965 cookies, be more strict about domains when setting and returning
+:rfc:`2965` cookies, be more strict about domains when setting and returning
 Netscape cookies, and block some domains from setting cookies or having them
 returned::
 
diff --git a/Doc/library/imaplib.rst b/Doc/library/imaplib.rst
index 1632eb7..2e2c59c 100644
--- a/Doc/library/imaplib.rst
+++ b/Doc/library/imaplib.rst
@@ -342,7 +342,7 @@
 
 .. method:: IMAP4.namespace()
 
-   Returns IMAP namespaces as defined in RFC2342.
+   Returns IMAP namespaces as defined in :rfc:`2342`.
 
 
 .. method:: IMAP4.noop()
diff --git a/Doc/library/logging.handlers.rst b/Doc/library/logging.handlers.rst
index f7262e6..bdf16a8 100644
--- a/Doc/library/logging.handlers.rst
+++ b/Doc/library/logging.handlers.rst
@@ -596,7 +596,7 @@
          (See: :issue:`12168`.) In earlier versions, the message sent to the
          syslog daemons was always terminated with a NUL byte, because early
          versions of these daemons expected a NUL terminated message - even
-         though it's not in the relevant specification (RFC 5424). More recent
+         though it's not in the relevant specification (:rfc:`5424`). More recent
          versions of these daemons don't expect the NUL byte but strip it off
          if it's there, and even more recent daemons (which adhere more closely
          to RFC 5424) pass the NUL byte on as part of the message.
diff --git a/Doc/library/logging.rst b/Doc/library/logging.rst
index 9a54bf9..6b48d64 100644
--- a/Doc/library/logging.rst
+++ b/Doc/library/logging.rst
@@ -516,7 +516,7 @@
    initialized with a format string for the message as a whole, as well as a
    format string for the date/time portion of a message.  If no *fmt* is
    specified, ``'%(message)s'`` is used.  If no *datefmt* is specified, an
-   ISO8601-like (or RFC3339-like) date format is used. See the
+   ISO8601-like (or :rfc:`3339`-like) date format is used. See the
    :meth:`formatTime` documentation for more details.
 
    The *style* parameter can be one of '%', '{' or '$' and determines how
diff --git a/Doc/library/nntplib.rst b/Doc/library/nntplib.rst
index 2c3cd8d..d8ef8a6 100644
--- a/Doc/library/nntplib.rst
+++ b/Doc/library/nntplib.rst
@@ -542,7 +542,7 @@
       is supplied, then the returned *list* is an empty list. This is an optional NNTP
       extension, and may not be supported by all servers.
 
-      RFC2980 says "It is suggested that this extension be deprecated".  Use
+      :rfc:`2980` says "It is suggested that this extension be deprecated".  Use
       :meth:`descriptions` or :meth:`description` instead.
 
 
diff --git a/Doc/library/ssl.rst b/Doc/library/ssl.rst
index 14eac2c..7a05824 100644
--- a/Doc/library/ssl.rst
+++ b/Doc/library/ssl.rst
@@ -2638,25 +2638,25 @@
    `SSL/TLS Strong Encryption: An Introduction <https://httpd.apache.org/docs/trunk/en/ssl/ssl_intro.html>`_
        Intro from the Apache HTTP Server documentation
 
-   `RFC 1422: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management <https://www.ietf.org/rfc/rfc1422>`_
+   :rfc:`RFC 1422: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management <1422>`
        Steve Kent
 
-   `RFC 4086: Randomness Requirements for Security <https://datatracker.ietf.org/doc/rfc4086/>`_
+   :rfc:`RFC 4086: Randomness Requirements for Security <4086>`
        Donald E., Jeffrey I. Schiller
 
-   `RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile <https://datatracker.ietf.org/doc/rfc5280/>`_
+   :rfc:`RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile <5280>`
        D. Cooper
 
-   `RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 <https://tools.ietf.org/html/rfc5246>`_
+   :rfc:`RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 <5246>`
        T. Dierks et. al.
 
-   `RFC 6066: Transport Layer Security (TLS) Extensions <https://tools.ietf.org/html/rfc6066>`_
+   :rfc:`RFC 6066: Transport Layer Security (TLS) Extensions <6066>`
        D. Eastlake
 
    `IANA TLS: Transport Layer Security (TLS) Parameters <https://www.iana.org/assignments/tls-parameters/tls-parameters.xml>`_
        IANA
 
-   `RFC 7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) <https://tools.ietf.org/html/rfc7525>`_
+   :rfc:`RFC 7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) <7525>`
        IETF
 
    `Mozilla's Server Side TLS recommendations <https://wiki.mozilla.org/Security/Server_Side_TLS>`_
diff --git a/Doc/library/stringprep.rst b/Doc/library/stringprep.rst
index e7fae56..330032b 100644
--- a/Doc/library/stringprep.rst
+++ b/Doc/library/stringprep.rst
@@ -26,7 +26,7 @@
 procedure are part of the profile. One example of a ``stringprep`` profile is
 ``nameprep``, which is used for internationalized domain names.
 
-The module :mod:`stringprep` only exposes the tables from RFC 3454. As these
+The module :mod:`stringprep` only exposes the tables from :rfc:`3454`. As these
 tables would be very large to represent them as dictionaries or lists, the
 module uses the Unicode character database internally. The module source code
 itself was generated using the ``mkstringprep.py`` utility.
diff --git a/Doc/library/urllib.error.rst b/Doc/library/urllib.error.rst
index 5517b04..f7d47ed 100644
--- a/Doc/library/urllib.error.rst
+++ b/Doc/library/urllib.error.rst
@@ -41,8 +41,7 @@
 
    .. attribute:: code
 
-      An HTTP status code as defined in `RFC 2616
-      <http://www.faqs.org/rfcs/rfc2616.html>`_.  This numeric value corresponds
+      An HTTP status code as defined in :rfc:`2616`.  This numeric value corresponds
       to a value found in the dictionary of codes as found in
       :attr:`http.server.BaseHTTPRequestHandler.responses`.
 
diff --git a/Doc/library/urllib.parse.rst b/Doc/library/urllib.parse.rst
index c0a388c..2d3488b 100644
--- a/Doc/library/urllib.parse.rst
+++ b/Doc/library/urllib.parse.rst
@@ -468,7 +468,7 @@
    *string* may be either a :class:`str` or a :class:`bytes`.
 
    .. versionchanged:: 3.7
-      Moved from RFC 2396 to RFC 3986 for quoting URL strings. "~" is now
+      Moved from :rfc:`2396` to :rfc:`3986` for quoting URL strings. "~" is now
       included in the set of reserved characters.
 
    The optional *encoding* and *errors* parameters specify how to deal with
diff --git a/Doc/library/urllib.request.rst b/Doc/library/urllib.request.rst
index 413d8b6..b7116fa 100644
--- a/Doc/library/urllib.request.rst
+++ b/Doc/library/urllib.request.rst
@@ -232,7 +232,7 @@
    containing the image.
 
    *unverifiable* should indicate whether the request is unverifiable,
-   as defined by RFC 2965.  It defaults to ``False``.  An unverifiable
+   as defined by :rfc:`2965`.  It defaults to ``False``.  An unverifiable
    request is one whose URL the user did not have the option to
    approve.  For example, if the request is for an image in an HTML
    document, and the user had no option to approve the automatic
@@ -504,7 +504,7 @@
 .. attribute:: Request.unverifiable
 
    boolean, indicates whether the request is unverifiable as defined
-   by RFC 2965.
+   by :rfc:`2965`.
 
 .. attribute:: Request.method
 
diff --git a/Doc/library/uuid.rst b/Doc/library/uuid.rst
index 8ec75a7..09c56e5 100644
--- a/Doc/library/uuid.rst
+++ b/Doc/library/uuid.rst
@@ -1,5 +1,5 @@
-:mod:`uuid` --- UUID objects according to RFC 4122
-==================================================
+:mod:`uuid` --- UUID objects according to :rfc:`4122`
+=====================================================
 
 .. module:: uuid
    :synopsis: UUID objects (universally unique identifiers) according to RFC 4122
@@ -64,7 +64,7 @@
 
    Exactly one of *hex*, *bytes*, *bytes_le*, *fields*, or *int* must be given.
    The *version* argument is optional; if given, the resulting UUID will have its
-   variant and version number set according to RFC 4122, overriding bits in the
+   variant and version number set according to :rfc:`4122`, overriding bits in the
    given *hex*, *bytes*, *bytes_le*, *fields*, or *int*.
 
    Comparison of UUID objects are made by way of comparing their
@@ -127,7 +127,7 @@
 
 .. attribute:: UUID.urn
 
-   The UUID as a URN as specified in RFC 4122.
+   The UUID as a URN as specified in :rfc:`4122`.
 
 
 .. attribute:: UUID.variant
@@ -158,7 +158,7 @@
    runs, it may launch a separate program, which could be quite slow.  If all
    attempts to obtain the hardware address fail, we choose a random 48-bit
    number with the multicast bit (least significant bit of the first octet)
-   set to 1 as recommended in RFC 4122.  "Hardware address" means the MAC
+   set to 1 as recommended in :rfc:`4122`.  "Hardware address" means the MAC
    address of a network interface.  On a machine with multiple network
    interfaces, universally administered MAC addresses (i.e. where the second
    least significant bit of the first octet is *unset*) will be preferred over
diff --git a/Doc/library/wsgiref.rst b/Doc/library/wsgiref.rst
index b0ef346..2d9b7b3 100644
--- a/Doc/library/wsgiref.rst
+++ b/Doc/library/wsgiref.rst
@@ -397,7 +397,7 @@
    Wrap *application* and return a new WSGI application object.  The returned
    application will forward all requests to the original *application*, and will
    check that both the *application* and the server invoking it are conforming to
-   the WSGI specification and to RFC 2616.
+   the WSGI specification and to :rfc:`2616`.
 
    Any detected nonconformance results in an :exc:`AssertionError` being raised;
    note, however, that how these errors are handled is server-dependent.  For
diff --git a/Doc/library/xmlrpc.client.rst b/Doc/library/xmlrpc.client.rst
index 390828e..ed2ccae 100644
--- a/Doc/library/xmlrpc.client.rst
+++ b/Doc/library/xmlrpc.client.rst
@@ -328,7 +328,7 @@
       Write the XML-RPC base 64 encoding of this binary item to the *out* stream object.
 
       The encoded data will have newlines every 76 characters as per
-      `RFC 2045 section 6.8 <https://tools.ietf.org/html/rfc2045#section-6.8>`_,
+      :rfc:`RFC 2045 section 6.8 <2045#section-6.8>`,
       which was the de facto standard base64 specification when the
       XML-RPC spec was written.