Update doc for RFC 6733

1 files changed, 10 insertions, 12 deletions

diff --git a/lib/diameter/doc/src/diameter_dict.xml b/lib/diameter/doc/src/diameter_dict.xml
index eb6cf9ba86..8b0687a22e 100644
--- a/lib/diameter/doc/src/diameter_dict.xml
+++ b/lib/diameter/doc/src/diameter_dict.xml
@@ -77,7 +77,7 @@ AVPs of type Enumerated.</p>
 
 <p>
 The diameter application includes three dictionary modules
-corresponding to applications defined in section 2.4 of RFC 3588:
+corresponding to applications defined in section 2.4 of &the_rfc;:
 <c>diameter_gen_base_rfc3588</c> for the Diameter Common Messages
 application with application identifier 0,
 <c>diameter_gen_accounting</c> for the Diameter Base Accounting
@@ -258,7 +258,7 @@ is equivalent to using <c>@avp_vendor_id</c> with a copy of the
 dictionary's definitions but the former makes for easier reuse.</p>
 
 <p>
-All dictionaries should typically inherit RFC3588 AVPs from
+All dictionaries should typically inherit &the_rfc; AVPs from
 <c>diameter_gen_base_rfc3588</c>.</p>
 
 <p>
@@ -299,9 +299,7 @@ Requested-Information  353  Enumerated   V
 
 <warning>
 <p>
-The P flag has been deprecated by the Diameter Maintenance
-and Extensions Working Group of the IETF and should be omitted
-to conform to the current draft standard.</p>
+The P flag has been deprecated by &the_rfc;.</p>
 </warning>
 
 </item>
@@ -355,7 +353,7 @@ Framed-IP-Address
 <p>
 Defines the messages of the application.
 The section content consists of definitions of the form specified in
-section 3.2 of RFC 3588, "Command Code ABNF specification".</p>
+section 3.2 of &the_rfc;, "Command Code Format Specification".</p>
 
 <!-- RFC 4740 RTR/RTA -->
 <pre>
@@ -403,7 +401,7 @@ RTA ::= &lt; Diameter Header: 287, PXY >
 Defines the contents of the AVPs of the application having type
 Grouped.
 The section content consists of definitions of the form specified in
-section 4.4 of RFC 3588, "Grouped AVP Values".</p>
+section 4.4 of &the_rfc;, "Grouped AVP Values".</p>
 
 <p>
 Example:</p>
@@ -507,7 +505,7 @@ type and number of times the AVP can occur.
 In particular, an AVP which is specified as occurring exactly once is
 encoded as a value of the AVP's type while an AVP with any other
 specification is encoded as a list of values of the AVP's type.
-The AVP's type is as specified in the AVP definition, the RFC 3588
+The AVP's type is as specified in the AVP definition, the &the_rfc;
 types being described below.</p>
 
 <marker id="DATA_TYPES"/>
@@ -520,7 +518,7 @@ types being described below.</p>
 
 <p>
 The data formats defined in sections 4.2 ("Basic AVP Data
-Formats") and 4.3 ("Derived AVP Data Formats") of RFC 3588 are encoded
+Formats") and 4.3 ("Derived AVP Data Formats") of &the_rfc; are encoded
 as values of the types defined here.
 Values are passed to &mod_call;
 in a request record when sending a request, returned in a resulting
@@ -595,8 +593,8 @@ where
 
 <p>
 Additionally, values that can be encoded are
-limited by way of their encoding as four octets as required by RFC
-3588 with the required extension from RFC 2030.
+limited by way of their encoding as four octets as required by
+&the_rfc; with the required extension from RFC 2030.
 In particular, only values between <c>{{1968,1,20},{3,14,8}}</c>
 and <c>{{2104,2,26},{9,42,23}}</c> (both inclusive) can be encoded.</p>
 
@@ -640,7 +638,7 @@ where
 On encode, fields port, transport and protocol default to 3868, sctp
 and diameter respectively.
 The grammar of an OctetString-valued DiameterURI() is as specified in
-section 4.3 of RFC 3588.
+section 4.3 of &the_rfc;.
 The record representation is used on decode.</p>
 
 <marker id="Enumerated"/>