Commit d5428593 authored by Peter Eisentraut's avatar Peter Eisentraut

doc: Update RFC URLs

Consistently use the IETF HTML links instead of a random mix of
different sites and formats.  Correct one RFC number and fix one broken
link.
parent 79f457e5
...@@ -941,7 +941,7 @@ omicron bryanh guest1 ...@@ -941,7 +941,7 @@ omicron bryanh guest1
<para> <para>
<literal>scram-sha-256</> performs SCRAM-SHA-256 authentication, as <literal>scram-sha-256</> performs SCRAM-SHA-256 authentication, as
described in described in
<ulink url="https://tools.ietf.org/html/rfc5802">RFC5802</ulink>. It <ulink url="https://tools.ietf.org/html/rfc7677">RFC 7677</ulink>. It
is a challenge-response scheme, that prevents password sniffing on is a challenge-response scheme, that prevents password sniffing on
untrusted connections. It is more secure than the <literal>md5</> untrusted connections. It is more secure than the <literal>md5</>
method, but might not be supported by older clients. method, but might not be supported by older clients.
......
...@@ -13,7 +13,7 @@ ...@@ -13,7 +13,7 @@
<para> <para>
JSON data types are for storing JSON (JavaScript Object Notation) JSON data types are for storing JSON (JavaScript Object Notation)
data, as specified in <ulink url="http://rfc7159.net/rfc7159">RFC data, as specified in <ulink url="https://tools.ietf.org/html/rfc7159">RFC
7159</ulink>. Such data can also be stored as <type>text</type>, but 7159</ulink>. Such data can also be stored as <type>text</type>, but
the JSON data types have the advantage of enforcing that each the JSON data types have the advantage of enforcing that each
stored value is valid according to the JSON rules. There are also stored value is valid according to the JSON rules. There are also
......
...@@ -775,7 +775,7 @@ PGPing PQping(const char *conninfo); ...@@ -775,7 +775,7 @@ PGPing PQping(const char *conninfo);
connection parameters. There are two accepted formats for these strings: connection parameters. There are two accepted formats for these strings:
plain <literal>keyword = value</literal> strings plain <literal>keyword = value</literal> strings
and URIs. URIs generally follow and URIs. URIs generally follow
<ulink url="http://www.ietf.org/rfc/rfc3986.txt">RFC <ulink url="https://tools.ietf.org/html/rfc3986">RFC
3986</ulink>, except that multi-host connection strings are allowed 3986</ulink>, except that multi-host connection strings are allowed
as further described below. as further described below.
</para> </para>
......
...@@ -1317,15 +1317,15 @@ gen_random_uuid() returns uuid ...@@ -1317,15 +1317,15 @@ gen_random_uuid() returns uuid
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para><ulink url="http://www.ietf.org/rfc/rfc4880.txt"></ulink></para> <para><ulink url="https://tools.ietf.org/html/rfc4880"></ulink></para>
<para>OpenPGP message format.</para> <para>OpenPGP message format.</para>
</listitem> </listitem>
<listitem> <listitem>
<para><ulink url="http://www.ietf.org/rfc/rfc1321.txt"></ulink></para> <para><ulink url="https://tools.ietf.org/html/rfc1321"></ulink></para>
<para>The MD5 Message-Digest Algorithm.</para> <para>The MD5 Message-Digest Algorithm.</para>
</listitem> </listitem>
<listitem> <listitem>
<para><ulink url="http://www.ietf.org/rfc/rfc2104.txt"></ulink></para> <para><ulink url="https://tools.ietf.org/html/rfc2104"></ulink></para>
<para>HMAC: Keyed-Hashing for Message Authentication.</para> <para>HMAC: Keyed-Hashing for Message Authentication.</para>
</listitem> </listitem>
<listitem> <listitem>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment