[Python-checkins] [3.6] bpo-33641: Convert RFC references into links. (GH-7103) (GH-7276)
Serhiy Storchaka
webhook-mailer at python.org
Thu May 31 02:11:10 EDT 2018
https://github.com/python/cpython/commit/55d9e865cb3b50587c17c8a7beee090c4ac8d535
commit: 55d9e865cb3b50587c17c8a7beee090c4ac8d535
branch: 3.6
author: Serhiy Storchaka <storchaka at gmail.com>
committer: GitHub <noreply at github.com>
date: 2018-05-31T09:11:07+03:00
summary:
[3.6] bpo-33641: Convert RFC references into links. (GH-7103) (GH-7276)
85% of them are already links.
(cherry picked from commit 0a36ac1a09587735237c5978ebd046313922869c)
files:
M Doc/howto/logging-cookbook.rst
M Doc/howto/logging.rst
M Doc/howto/urllib2.rst
M Doc/library/binascii.rst
M Doc/library/codecs.rst
M Doc/library/email.examples.rst
M Doc/library/ftplib.rst
M Doc/library/hashlib.rst
M Doc/library/http.cookiejar.rst
M Doc/library/imaplib.rst
M Doc/library/logging.handlers.rst
M Doc/library/logging.rst
M Doc/library/nntplib.rst
M Doc/library/ssl.rst
M Doc/library/stringprep.rst
M Doc/library/urllib.error.rst
M Doc/library/urllib.request.rst
M Doc/library/uuid.rst
M Doc/library/wsgiref.rst
M Doc/library/xmlrpc.client.rst
M Doc/tutorial/stdlib.rst
M Doc/whatsnew/2.4.rst
diff --git a/Doc/howto/logging-cookbook.rst b/Doc/howto/logging-cookbook.rst
index b43dc2b1fa09..96d550c457b8 100644
--- a/Doc/howto/logging-cookbook.rst
+++ b/Doc/howto/logging-cookbook.rst
@@ -1652,11 +1652,11 @@ works::
Inserting a BOM into messages sent to a SysLogHandler
-----------------------------------------------------
-`RFC 5424 <https://tools.ietf.org/html/rfc5424>`_ requires that a
+:rfc:`5424` requires that a
Unicode message be sent to a syslog daemon as a set of bytes which have the
following structure: an optional pure-ASCII component, followed by a UTF-8 Byte
-Order Mark (BOM), followed by Unicode encoded using UTF-8. (See the `relevant
-section of the specification <https://tools.ietf.org/html/rfc5424#section-6>`_.)
+Order Mark (BOM), followed by Unicode encoded using UTF-8. (See the
+:rfc:`relevant section of the specification <5424#section-6>`.)
In Python 3.1, code was added to
:class:`~logging.handlers.SysLogHandler` to insert a BOM into the message, but
@@ -1666,7 +1666,7 @@ appear before it.
As this behaviour is broken, the incorrect BOM insertion code is being removed
from Python 3.2.4 and later. However, it is not being replaced, and if you
-want to produce RFC 5424-compliant messages which include a BOM, an optional
+want to produce :rfc:`5424`-compliant messages which include a BOM, an optional
pure-ASCII sequence before it and arbitrary Unicode after it, encoded using
UTF-8, then you need to do the following:
@@ -1689,7 +1689,7 @@ UTF-8, then you need to do the following:
The formatted message *will* be encoded using UTF-8 encoding by
``SysLogHandler``. If you follow the above rules, you should be able to produce
-RFC 5424-compliant messages. If you don't, logging may not complain, but your
+:rfc:`5424`-compliant messages. If you don't, logging may not complain, but your
messages will not be RFC 5424-compliant, and your syslog daemon may complain.
diff --git a/Doc/howto/logging.rst b/Doc/howto/logging.rst
index 5976c32d93b0..9914f8d154ab 100644
--- a/Doc/howto/logging.rst
+++ b/Doc/howto/logging.rst
@@ -297,7 +297,7 @@ which should print something like this:
2010-12-12 11:41:42,612 is when this event was logged.
The default format for date/time display (shown above) is like ISO8601 or
-RFC 3339. If you need more control over the formatting of the date/time, provide
+:rfc:`3339`. If you need more control over the formatting of the date/time, provide
a *datefmt* argument to ``basicConfig``, as in this example::
import logging
diff --git a/Doc/howto/urllib2.rst b/Doc/howto/urllib2.rst
index 8b93d701869d..7505e7564422 100644
--- a/Doc/howto/urllib2.rst
+++ b/Doc/howto/urllib2.rst
@@ -239,7 +239,7 @@ a different URL, urllib will handle that for you). For those it can't handle,
urlopen will raise an :exc:`HTTPError`. Typical errors include '404' (page not
found), '403' (request forbidden), and '401' (authentication required).
-See section 10 of RFC 2616 for a reference on all the HTTP error codes.
+See section 10 of :rfc:`2616` for a reference on all the HTTP error codes.
The :exc:`HTTPError` instance raised will have an integer 'code' attribute, which
corresponds to the error sent by the server.
@@ -252,7 +252,7 @@ codes in the 100--299 range indicate success, you will usually only see error
codes in the 400--599 range.
:attr:`http.server.BaseHTTPRequestHandler.responses` is a useful dictionary of
-response codes in that shows all the response codes used by RFC 2616. The
+response codes in that shows all the response codes used by :rfc:`2616`. The
dictionary is reproduced here for convenience ::
# Table mapping response codes to messages; entries have the
diff --git a/Doc/library/binascii.rst b/Doc/library/binascii.rst
index 0476f507717c..adb087ef8826 100644
--- a/Doc/library/binascii.rst
+++ b/Doc/library/binascii.rst
@@ -77,7 +77,7 @@ The :mod:`binascii` module defines the following functions:
*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 74b24e10ede6..24008a0b3f00 100644
--- a/Doc/library/codecs.rst
+++ b/Doc/library/codecs.rst
@@ -1425,7 +1425,7 @@ to the user.
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 @@ parameters, such as :mod:`http.client` and :mod:`ftplib`, accept Unicode host
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 84e9aee0bc48..fc964622809d 100644
--- a/Doc/library/email.examples.rst
+++ b/Doc/library/email.examples.rst
@@ -12,7 +12,7 @@ text content and the addresses may contain unicode characters):
.. 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 7291dfe84811..6c39f9a59fc1 100644
--- a/Doc/library/ftplib.rst
+++ b/Doc/library/ftplib.rst
@@ -295,7 +295,7 @@ followed by ``lines`` for the text version or ``binary`` for the binary version.
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 3a27a5b566f5..9bd39cb4a51b 100644
--- a/Doc/library/hashlib.rst
+++ b/Doc/library/hashlib.rst
@@ -283,7 +283,7 @@ BLAKE2
.. 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 @@ Domain Dedication 1.0 Universal:
* *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 5370601544c7..d8da6683a3a5 100644
--- a/Doc/library/http.cookiejar.rst
+++ b/Doc/library/http.cookiejar.rst
@@ -88,7 +88,7 @@ The following classes are provided:
: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 @@ The following classes are provided:
.. 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 following classes are provided:
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 @@ writing.
.. 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 @@ be assigned to.
.. 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 @@ DefaultCookiePolicy Objects
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 @@ all be assigned to.
.. 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 @@ General strictness switches:
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 @@ Netscape protocol strictness switches:
.. 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 @@ both flags are set).
.. 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 @@ Cookie Objects
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 @@ internal consistency, so you should know what you're doing if you do that.
.. 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 @@ internal consistency, so you should know what you're doing if you do that.
.. 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 @@ cookies (assumes Unix/Netscape convention for location of the cookies file)::
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 1632eb7aed36..2e2c59c9ce00 100644
--- a/Doc/library/imaplib.rst
+++ b/Doc/library/imaplib.rst
@@ -342,7 +342,7 @@ An :class:`IMAP4` instance has the following methods:
.. 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 6bb7b13af813..a31ee31922fc 100644
--- a/Doc/library/logging.handlers.rst
+++ b/Doc/library/logging.handlers.rst
@@ -583,7 +583,7 @@ supports sending logging messages to a remote or local Unix syslog.
(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 d0a6e613d8ee..3072a53ef4bf 100644
--- a/Doc/library/logging.rst
+++ b/Doc/library/logging.rst
@@ -516,7 +516,7 @@ The useful mapping keys in a :class:`LogRecord` are given in the section on
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 2c3cd8dafe6e..d8ef8a692a95 100644
--- a/Doc/library/nntplib.rst
+++ b/Doc/library/nntplib.rst
@@ -542,7 +542,7 @@ them have been superseded by newer commands in :rfc:`3977`.
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 cb17742bcc8b..caf298ae02b8 100644
--- a/Doc/library/ssl.rst
+++ b/Doc/library/ssl.rst
@@ -2345,25 +2345,25 @@ with LibreSSL.
`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 <http://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 <http://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 e7fae5631d87..330032ba1c0b 100644
--- a/Doc/library/stringprep.rst
+++ b/Doc/library/stringprep.rst
@@ -26,7 +26,7 @@ define which tables it uses, and what other optional parts of the ``stringprep``
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 5517b04f5ddf..f7d47ed76aca 100644
--- a/Doc/library/urllib.error.rst
+++ b/Doc/library/urllib.error.rst
@@ -41,8 +41,7 @@ The following exceptions are raised by :mod:`urllib.error` as appropriate:
.. 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.request.rst b/Doc/library/urllib.request.rst
index 5a10f9571e9e..705517a32e33 100644
--- a/Doc/library/urllib.request.rst
+++ b/Doc/library/urllib.request.rst
@@ -232,7 +232,7 @@ The following classes are provided:
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 @@ request.
.. 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 edbf832529a6..6ac1ffb96584 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
@@ -42,7 +42,7 @@ random UUID.
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
@@ -105,7 +105,7 @@ random UUID.
.. 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
@@ -128,7 +128,7 @@ The :mod:`uuid` module defines the following functions:
Get the hardware address as a 48-bit positive integer. The first time this
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 its eighth bit set to 1 as recommended in RFC 4122. "Hardware address"
+ with its eighth bit set to 1 as recommended in :rfc:`4122`. "Hardware address"
means the MAC address of a network interface, and on a machine with multiple
network interfaces the MAC address of any one of them may be returned.
diff --git a/Doc/library/wsgiref.rst b/Doc/library/wsgiref.rst
index a1d446902b83..ddfc2e54732b 100644
--- a/Doc/library/wsgiref.rst
+++ b/Doc/library/wsgiref.rst
@@ -397,7 +397,7 @@ Paste" library.
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 390828ef3d98..ed2ccaeae07a 100644
--- a/Doc/library/xmlrpc.client.rst
+++ b/Doc/library/xmlrpc.client.rst
@@ -328,7 +328,7 @@ Binary Objects
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.
diff --git a/Doc/tutorial/stdlib.rst b/Doc/tutorial/stdlib.rst
index 1dd06c233826..110e6e546668 100644
--- a/Doc/tutorial/stdlib.rst
+++ b/Doc/tutorial/stdlib.rst
@@ -317,7 +317,7 @@ sophisticated and robust capabilities of its larger packages. For example:
names, no direct knowledge or handling of XML is needed.
* The :mod:`email` package is a library for managing email messages, including
- MIME and other RFC 2822-based message documents. Unlike :mod:`smtplib` and
+ MIME and other :rfc:`2822`-based message documents. Unlike :mod:`smtplib` and
:mod:`poplib` which actually send and receive messages, the email package has
a complete toolset for building or decoding complex message structures
(including attachments) and for implementing internet encoding and header
diff --git a/Doc/whatsnew/2.4.rst b/Doc/whatsnew/2.4.rst
index 7c125ffd2ad0..7e11c98399cc 100644
--- a/Doc/whatsnew/2.4.rst
+++ b/Doc/whatsnew/2.4.rst
@@ -998,7 +998,7 @@ complete list of changes, or look through the CVS logs for all the details.
that lets you perform a limited number of passes through the polling loop. The
default is still to loop forever.
-* The :mod:`base64` module now has more complete RFC 3548 support for Base64,
+* The :mod:`base64` module now has more complete :rfc:`3548` support for Base64,
Base32, and Base16 encoding and decoding, including optional case folding and
optional alternative alphabets. (Contributed by Barry Warsaw.)
More information about the Python-checkins
mailing list