docs: ulink all references to RFC's
authorHeikki Linnakangas
Tue, 1 Dec 2020 12:36:30 +0000 (14:36 +0200)
committerHeikki Linnakangas
Tue, 1 Dec 2020 12:36:30 +0000 (14:36 +0200)
Make sure that the first mentions of RFC's are ulinked to their ietf.org
entry, and subsequent ones are marked as acronyms. This makes references
to RFC's consistent across the documentation.

Author: Daniel Gustafsson
Discussion: https://www.postgresql.org/message-id/2C697878-4D01-4F06-8312-2FEDE931E973%40yesql.se

12 files changed:
doc/src/sgml/catalogs.sgml
doc/src/sgml/charset.sgml
doc/src/sgml/client-auth.sgml
doc/src/sgml/datatype.sgml
doc/src/sgml/ecpg.sgml
doc/src/sgml/func.sgml
doc/src/sgml/json.sgml
doc/src/sgml/libpq.sgml
doc/src/sgml/pgcrypto.sgml
doc/src/sgml/protocol.sgml
doc/src/sgml/textsearch.sgml
doc/src/sgml/uuid-ossp.sgml

index 569841398b4ed3038ca9e9424430b7d6d3710d9f..79069ddfabe1e1f92f5aedeffc0f0a40011b72d9 100644 (file)
@@ -1598,7 +1598,7 @@ SCRAM-SHA-256$<iteration count>:&l
 
    where saltStoredKey and
    ServerKey are in Base64 encoded format. This format is
-   the same as that specified by RFC 5803.
+   the same as that specified by RFC 5803.
   
 
   
index e151987eff686b2cd3908fbcea889627b30434eb..cebc09ef91459faafa714b64e223f7020230c5a0 100644 (file)
@@ -2663,7 +2663,7 @@ RESET client_encoding;
       
 
       
-       RFC 3629
+       RFC 3629
 
        
         
index bad3c3469c951ff128712c43d7756f6a2d80f01f..a0a9ac9eed55164e44b600766b73b3bf27868753 100644 (file)
@@ -948,7 +948,8 @@ omicron         bryanh                  guest1
     
      
       Ident authentication, which
-      relies on an Identification Protocol (RFC 1413)
+      relies on an Identification Protocol
+      (RFC 1413)
       service on the client's machine.  (On local Unix-socket connections,
       this is treated as peer authentication.)
      
@@ -1198,7 +1199,8 @@ omicron         bryanh                  guest1
 
    
     GSSAPI is an industry-standard protocol
-    for secure authentication defined in RFC 2743.
+    for secure authentication defined in
+    RFC 2743.
 
     PostgreSQL
     supports GSSAPI for use as either an encrypted,
@@ -1503,7 +1505,8 @@ omicron         bryanh                  guest1
 
    
     The Identification Protocol is described in
-    RFC 1413. Virtually every Unix-like
+    RFC 1413.
+    Virtually every Unix-like
     operating system ships with an ident server that listens on TCP
     port 113 by default. The basic functionality of an ident server
     is to answer questions like What user initiated the
@@ -1671,8 +1674,8 @@ omicron         bryanh                  guest1
        
         Set to 1 to make the connection between PostgreSQL and the LDAP server
         use TLS encryption.  This uses the StartTLS
-        operation per RFC 4513.  See also the ldapscheme
-        option for an alternative.
+        operation per RFC 4513.
+        See also the ldapscheme option for an alternative.
        
       
      
@@ -1766,7 +1769,8 @@ omicron         bryanh                  guest1
        ldapurl
        
         
-         An RFC 4516 LDAP URL.  This is an alternative way to write some of the
+         An RFC 4516
+         LDAP URL.  This is an alternative way to write some of the
          other LDAP options in a more compact and standard form.  The format is
 
 ldap[s]://host[:port]/basedn[?[attribute][?[scope][?[filter]]]]
@@ -1827,7 +1831,8 @@ ldap[s]://host[:port]/
      If PostgreSQL was compiled with
      OpenLDAP as the LDAP client library, the
      ldapserver setting may be omitted.  In that case, a
-     list of host names and ports is looked up via RFC 2782 DNS SRV records.
+     list of host names and ports is looked up via
+     RFC 2782 DNS SRV records.
      The name _ldap._tcp.DOMAIN is looked up, where
      DOMAIN is extracted from ldapbasedn.
    
index c2951854b5ce3d28415aaadb8513480e5df11ee2..5c8a92e250834163d2f540fbbedb1f6f2b7539bf 100644 (file)
@@ -2384,7 +2384,8 @@ TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02'
       ISO 8601 specifies the use of uppercase letter T to separate
       the date and time.  PostgreSQL accepts that format on
       input, but on output it uses a space rather than T, as shown
-      above.  This is for readability and for consistency with RFC 3339 as
+      above.  This is for readability and for consistency with
+      RFC 3339 as
       well as some other database systems.
      
     
@@ -4247,7 +4248,8 @@ SELECT to_tsvector( 'postgraduate' ), to_tsquery( 'postgres:*' );
 
    
     The data type uuid stores Universally Unique Identifiers
-    (UUID) as defined by RFC 4122, ISO/IEC 9834-8:2005, and related standards.
+    (UUID) as defined by RFC 4122,
+    ISO/IEC 9834-8:2005, and related standards.
     (Some systems refer to this data type as a globally unique identifier, or
     GUID,GUID instead.)  This
     identifier is a 128-bit quantity that is generated by an algorithm chosen
index 14dcbdb4e32a725d2b90296ebc723db6fe017d74..0fef9bfcbe5d91b17e5b214f3736ea74119d3ce8 100644 (file)
@@ -3226,7 +3226,7 @@ int PGTYPEStimestamp_fmt_asc(timestamp *ts, char *output, int str_len, char *fmt
            %z - is replaced by the time zone offset from
            UTC; a leading plus sign stands for east of UTC, a minus sign for
            west of UTC, hours and minutes follow with two digits each and no
-           delimiter between them (common form for RFC 822 date headers).
+           delimiter between them (common form for RFC 822 date headers).
           
          
          
index 1ea88a8c6717a203bc2f6b2aa4e9c2c5fc16f5e7..df29af6371a296c02e506fd4851d218b6efc8a03 100644 (file)
@@ -4449,7 +4449,7 @@ SELECT format('Testing %3$s, %2$s, %s', 'one', 'two', 'three');
       
        The base64 format is that
        of RFC
-       2045 Section 6.8.  As per the RFC, encoded lines are
+       2045 Section 6.8.  As per the RFC, encoded lines are
        broken at 76 characters.  However instead of the MIME CRLF
        end-of-line marker, only a newline is used for end-of-line.
        The decode function ignores carriage-return,
index c0a6554d4d7eea1fc67d0a79e144af805bdac32f..5b9a5557a40fd8bd1b40813f1a1d4c06f931356e 100644 (file)
@@ -61,7 +61,7 @@
  
 
  
-  RFC 7159 specifies that JSON strings should be encoded in UTF8.
+  RFC 7159 specifies that JSON strings should be encoded in UTF8.
   It is therefore not possible for the JSON
   types to conform rigidly to the JSON specification unless the database
   encoding is UTF8. Attempts to directly include characters that
@@ -71,7 +71,7 @@
  
 
  
-  RFC 7159 permits JSON strings to contain Unicode escape sequences
+  RFC 7159 permits JSON strings to contain Unicode escape sequences
   denoted by \uXXXX.  In the input
   function for the json type, Unicode escapes are allowed
   regardless of the database encoding, and are checked only for syntactic
index 1553f9c89c7f6cdfcb687a78286a75d9c79241d0..67c5d4c36bd6d83f87deff43139d3b1d2316492d 100644 (file)
@@ -7462,8 +7462,9 @@ user=admin
    ldap:// will be recognized as an LDAP URL and an
    LDAP query will be performed. The result must be a list of
    keyword = value pairs which will be used to set
-   connection options.  The URL must conform to RFC 1959 and be of the
-   form
+   connection options.  The URL must conform to
+   RFC 1959
+   and be of the form
 
 ldap://[hostname[:port]]/search_base?attribute?search_scope?filter
 
index 8748c64e2da6dd87232252758f1608806d0ba3d7..3d74e15ec9b79c9a5701bbbc36fe64dbdb0384aa 100644 (file)
@@ -437,7 +437,8 @@ gen_salt(type text [, iter_count integer ]) returns text
   PGP Encryption Functions
 
   
-   The functions here implement the encryption part of the OpenPGP (RFC 4880)
+   The functions here implement the encryption part of the OpenPGP
+   (RFC 4880)
    standard.  Supported are both symmetric-key and public-key encryption.
   
 
@@ -806,7 +807,7 @@ Applies to: pgp_sym_encrypt, pgp_pub_encrypt
    
     Whether to convert \n into \r\n when
     encrypting and \r\n to \n when
-    decrypting.  RFC 4880 specifies that text data should be stored using
+    decrypting.  RFC 4880 specifies that text data should be stored using
     \r\n line-feeds.  Use this to get fully RFC-compliant
     behavior.
    
@@ -823,7 +824,7 @@ Applies to: pgp_sym_encrypt, pgp_pub_encrypt, pgp_sym_decrypt, pgp_pub_decrypt
    
     Do not protect data with SHA-1.  The only good reason to use this
     option is to achieve compatibility with ancient PGP products, predating
-    the addition of SHA-1 protected packets to RFC 4880.
+    the addition of SHA-1 protected packets to RFC 4880.
     Recent gnupg.org and pgp.com software supports it fine.
    
 
index cee28889e1d4c75a7fb27e80fb6c864a8312d846..4899bacda7b0bdc027136c0209144d4b72430928 100644 (file)
@@ -1501,7 +1501,8 @@ SELCT 1/0;
     is willing or unwilling to perform GSSAPI encryption,
     respectively.  The frontend might close the connection at this point
     if it is dissatisfied with the response.  To continue after
-    G, using the GSSAPI C bindings as discussed in RFC2744
+    G, using the GSSAPI C bindings as discussed in
+    RFC 2744
     or equivalent, perform a GSSAPI initialization by
     calling gss_init_sec_context() in a loop and sending
     the result to the server, starting with an empty input and then with each
@@ -1616,7 +1617,8 @@ ErrorMessage.
    The implemented SASL mechanisms at the moment
    are SCRAM-SHA-256 and its variant with channel
    binding SCRAM-SHA-256-PLUS. They are described in
-   detail in RFC 7677 and RFC 5802.
+   detail in RFC 7677
+   and RFC 5802.
   
 
   
index 7bd8d53dc4e0b1c1542456d800e8fb50b88a6ef9..1e52d193b44b128718a0741a64e15ab64679be88 100644 (file)
@@ -2218,9 +2218,9 @@ LIMIT 10;
 
    
     email does not support all valid email characters as
-    defined by RFC 5322.  Specifically, the only non-alphanumeric
-    characters supported for email user names are period, dash, and
-    underscore.
+    defined by RFC 5322.
+    Specifically, the only non-alphanumeric characters supported for
+    email user names are period, dash, and underscore.
    
   
 
index 460be97fdd86a0cc3c83bfa27630687a65c8c65d..359d3c0128953e73c45fbf4ad56ea151e174d2bb 100644 (file)
@@ -28,8 +28,9 @@
   
     shows the functions available to
    generate UUIDs.
-   The relevant standards ITU-T Rec. X.667, ISO/IEC 9834-8:2005, and RFC
-   4122 specify four algorithms for generating UUIDs, identified by the
+   The relevant standards ITU-T Rec. X.667, ISO/IEC 9834-8:2005, and
+   RFC 4122
+   specify four algorithms for generating UUIDs, identified by the
    version numbers 1, 3, 4, and 5.  (There is no version 2 algorithm.)
    Each of these algorithms could be suitable for a different set of
    applications.