Standardize links to RFC.

There were 70 links to https://datatracker.ietf.org/doc/html/
vs. 15 links https://www.rfc-editor.org/rfc/.

Also :rfc:`....` links to https://datatracker.ietf.org/doc/html/
by default.

While https://www.ietf.org/process/rfcs/#introduction says:

> The RFC Editor website is the authoritative site for RFCs.

the IETF Datatracker looks a bit better and has more information.

docs/faq/common.rst

@@ -131,8 +131,8 @@ How do I respond to pings?
 If you are referring to Ping_ and Pong_ frames defined in the WebSocket
 protocol, don't bother, because websockets handles them for you.
 
-.. _Ping: https://www.rfc-editor.org/rfc/rfc6455.html#section-5.5.2
-.. _Pong: https://www.rfc-editor.org/rfc/rfc6455.html#section-5.5.3
+.. _Ping: https://datatracker.ietf.org/doc/html/rfc6455.html#section-5.5.2
+.. _Pong: https://datatracker.ietf.org/doc/html/rfc6455.html#section-5.5.3
 
 If you are connecting to a server that defines its own heartbeat at the
 application level, then you need to build that logic into your application.

docs/howto/extensions.rst

@@ -7,7 +7,7 @@ During the opening handshake, WebSocket clients and servers negotiate which
 extensions_ will be used with which parameters. Then each frame is processed
 by extensions before being sent or after being received.
 
-.. _extensions: https://www.rfc-editor.org/rfc/rfc6455.html#section-9
+.. _extensions: https://datatracker.ietf.org/doc/html/rfc6455.html#section-9
 
 As a consequence, writing an extension requires implementing several classes:
 

docs/project/changelog.rst

@@ -1487,7 +1487,7 @@ New features
 
 * Added support for providing and checking Origin_.
 
-.. _Origin: https://www.rfc-editor.org/rfc/rfc6455.html#section-10.2
+.. _Origin: https://datatracker.ietf.org/doc/html/rfc6455.html#section-10.2
 
 .. _2.0:
 

docs/reference/extensions.rst

@@ -8,7 +8,7 @@ The WebSocket protocol supports extensions_.
 At the time of writing, there's only one `registered extension`_ with a public
 specification, WebSocket Per-Message Deflate.
 
-.. _extensions: https://www.rfc-editor.org/rfc/rfc6455.html#section-9
+.. _extensions: https://datatracker.ietf.org/doc/html/rfc6455.html#section-9
 .. _registered extension: https://www.iana.org/assignments/websocket/websocket.xhtml#extension-name
 
 Per-Message Deflate

docs/topics/design.rst

@@ -173,16 +173,16 @@ differences between a server and a client:
 - `closing the TCP connection`_: the server closes the connection immediately;
   the client waits for the server to do it.
 
-.. _client-to-server masking: https://www.rfc-editor.org/rfc/rfc6455.html#section-5.3
-.. _closing the TCP connection: https://www.rfc-editor.org/rfc/rfc6455.html#section-5.5.1
+.. _client-to-server masking: https://datatracker.ietf.org/doc/html/rfc6455.html#section-5.3
+.. _closing the TCP connection: https://datatracker.ietf.org/doc/html/rfc6455.html#section-5.5.1
 
 These differences are so minor that all the logic for `data framing`_, for
 `sending and receiving data`_ and for `closing the connection`_ is implemented
 in the same class, :class:`~protocol.WebSocketCommonProtocol`.
 
-.. _data framing: https://www.rfc-editor.org/rfc/rfc6455.html#section-5
-.. _sending and receiving data: https://www.rfc-editor.org/rfc/rfc6455.html#section-6
-.. _closing the connection: https://www.rfc-editor.org/rfc/rfc6455.html#section-7
+.. _data framing: https://datatracker.ietf.org/doc/html/rfc6455.html#section-5
+.. _sending and receiving data: https://datatracker.ietf.org/doc/html/rfc6455.html#section-6
+.. _closing the connection: https://datatracker.ietf.org/doc/html/rfc6455.html#section-7
 
 The :attr:`~protocol.WebSocketCommonProtocol.is_client` attribute tells which
 side a protocol instance is managing. This attribute is defined on the

docs/topics/keepalive.rst

@@ -33,8 +33,8 @@ Keepalive in websockets
 To avoid these problems, websockets runs a keepalive and heartbeat mechanism
 based on WebSocket Ping_ and Pong_ frames, which are designed for this purpose.
 
-.. _Ping: https://www.rfc-editor.org/rfc/rfc6455.html#section-5.5.2
-.. _Pong: https://www.rfc-editor.org/rfc/rfc6455.html#section-5.5.3
+.. _Ping: https://datatracker.ietf.org/doc/html/rfc6455.html#section-5.5.2
+.. _Pong: https://datatracker.ietf.org/doc/html/rfc6455.html#section-5.5.3
 
 It sends a Ping frame every 20 seconds. It expects a Pong frame in return within
 20 seconds. Else, it considers the connection broken and terminates it.
@@ -98,7 +98,7 @@ at regular intervals. Usually they expect Text_ frames rather than Ping_ frames,
 meaning that you must send them with :attr:`~asyncio.connection.Connection.send`
 rather than :attr:`~asyncio.connection.Connection.ping`.
 
-.. _Text: https://www.rfc-editor.org/rfc/rfc6455.html#section-5.6
+.. _Text: https://datatracker.ietf.org/doc/html/rfc6455.html#section-5.6
 
 In websockets, such keepalive mechanisms are considered as application-level
 because they rely on data frames. That's unlike the protocol-level keepalive

docs/topics/logging.rst

@@ -35,8 +35,8 @@ Instead, when running as a server, websockets logs one event when a
 `connection is established`_ and another event when a `connection is
 closed`_.
 
-.. _connection is established: https://www.rfc-editor.org/rfc/rfc6455.html#section-4
-.. _connection is closed: https://www.rfc-editor.org/rfc/rfc6455.html#section-7.1.4
+.. _connection is established: https://datatracker.ietf.org/doc/html/rfc6455.html#section-4
+.. _connection is closed: https://datatracker.ietf.org/doc/html/rfc6455.html#section-7.1.4
 
 By default, websockets doesn't log an event for every message. That would be
 excessive for many applications exchanging small messages at a fast rate. If