Merge branch 'fredrik/ssh/fix-idle-tests' into fredrik/ssh/rekeying

* fredrik/ssh/fix-idle-tests: (50 commits)
  Modifications to idle_time testcase
  Teach Win installer to handle redist on w2012/w8
  ssl: Receive port EXIT-message so that it does not get mixed up with the protocol-error message we are expecting
  ssl: Add and enhance tests
  ssl: Consider new server options when resuming a session
  Prepare release
  ssl: Add dependencies to Makefile
  Simplify the code for the generated info/0 function
  Don't try to work around a non-loadable NIF library
  Fix BER encoding when multiple levels of typedefs are used
  Update megaco documentation
  Update documentation for the asn1 application
  Fix other applications
  Fix use of asn1 in megaco
  Remove the unused asn1ct_gen_ber module
  Fix erroneous skipping for jinterface, erl_interface and ic
  kernel: Heart port needs to be unregistered
  Update preloaded modules
  Update primary bootstrap
  Update copyright years
  ...

15 files changed, 942 insertions, 194 deletions

diff --git a/lib/diameter/doc/src/diameter.xml b/lib/diameter/doc/src/diameter.xml
index bc42b75c7a..b7669b760b 100644
--- a/lib/diameter/doc/src/diameter.xml
+++ b/lib/diameter/doc/src/diameter.xml
@@ -1,5 +1,11 @@
 <?xml version="1.0" encoding="latin1" ?>
 <!DOCTYPE erlref SYSTEM "erlref.dtd" [
+  <!ENTITY make_ref
+  '<seealso marker="erts:erlang#make_ref-0">erlang:make_ref/0</seealso>'>
+  <!ENTITY transport_module
+  '<seealso marker="diameter_transport">transport module</seealso>'>
+  <!ENTITY dictionary
+  '<seealso marker="diameter_dict">dictionary</seealso>'>
   <!ENTITY % also SYSTEM "seealso.ent" >
   <!ENTITY % here SYSTEM "seehere.ent" >
   %also;
@@ -50,7 +56,7 @@ under the License.
 <p>
 This module provides the interface with which a user can
 implement a Diameter node that sends and receives messages using the
-Diameter protocol as defined in RFC 3588.</p>
+Diameter protocol as defined in &the_rfc;.</p>
 
 <p>
 Basic usage consists of creating a representation of a
@@ -67,7 +73,7 @@ Beware the difference between <em>diameter</em> (not capitalised) and
 <em>Diameter</em> (capitalised).
 The former refers to the Erlang application named diameter whose main
 api is defined here, the latter to Diameter protocol in the sense of
-RFC 3588.</p>
+&the_rfc;.</p>
 
 <p>
 The diameter application must be started before calling most functions
@@ -91,7 +97,7 @@ in this module.</p>
 <tag><c>UTF8String()</c></tag>
 <item>
 <p>
-Types corresponding to RFC 3588 AVP Data Formats.
+Types corresponding to &the_rfc; AVP Data Formats.
 Defined in &dict_data_types;.</p>
 
 <marker id="application_alias"/>
@@ -298,7 +304,7 @@ Has one of the following types.</p>
 <item>
 <p>
 An address list is available to the start function of a
-<seealso marker="diameter_transport">transport module</seealso>, which
+&transport_module;, which
 can return a new list for use in the subsequent CER or CEA.
 Host-IP-Address need not be specified if the transport start function
 returns an address list.</p>
@@ -312,7 +318,7 @@ returns an address list.</p>
 Origin-State-Id is optional but will be included in outgoing messages
 sent by diameter itself: CER/CEA, DWR/DWA and DPR/DPA.
 Setting a value of <c>0</c> (zero) is equivalent to not setting a
-value as documented in RFC 3588.
+value as documented in &the_rfc;.
 The function &origin_state_id;
 can be used as to retrieve a value that is computed when the diameter
 application is started.</p>
@@ -464,7 +470,7 @@ that matches no peer.</p>
 <p>
 The <c>host</c> and <c>realm</c> filters examine the
 outgoing request as passed to &call;,
-assuming that this is a record- or list-valued <c>&app_message;</c>,
+assuming that this is a record- or list-valued <c>&codec_message;</c>,
 and that the message contains at most one of each AVP.
 If this is not the case then the <c>{host|realm, &dict_DiameterIdentity;}</c>
 filters must be used to achieve the desired result.
@@ -529,8 +535,7 @@ connectivity.</p>
 
 <p>
 Note that a single <c>up</c>/<c>down</c> event for a given peer
-corresponds to one
-<seealso marker="diameter_app#Mod:peer_up-3">peer_up/peer_down</seealso>
+corresponds to one &app_peer_up;/&app_peer_down;
 callback for each of the Diameter applications negotiated during
 capablilities exchange.
 That is, the event communicates connectivity with the
@@ -677,7 +682,7 @@ info fields of forms other than the above.</p>
 The name of a service as passed to &start_service; and with which the
 service is identified.
 There can be at most one service with a given name on a given node.
-Note that <seealso marker="erts:erlang#make_ref-0">erlang:make_ref/0</seealso>
+Note that &make_ref;
 can be used to generate a service name that is somewhat unique.</p>
 
 <marker id="service_opt"/>
@@ -703,8 +708,7 @@ For an outgoing Diameter request, the relevant <c>&application_alias;</c> is
 passed to &call;, while for an
 incoming request the application identifier in the message
 header determines the application, the identifier being specified in
-the application's <seealso marker="diameter_dict">dictionary</seealso>
-file.</p>
+the application's &dictionary; file.</p>
 </item>
 
 <tag><c>{restrict_connections, false
@@ -749,7 +753,7 @@ as follows.</p>
 (H bsl N) bor (Id band ((1 bsl N) - 1))
 </pre>
 <p>
-Note that RFC 3588 requires that End-to-End identifiers remain unique
+Note that &the_rfc; requires that End-to-End identifiers remain unique
 for a period of at least 4 minutes and that this and the call rate
 places a lower bound on the appropriate values of <c>N</c>:
 at a rate of <c>R</c> requests per second an <c>N</c>-bit counter
@@ -951,7 +955,7 @@ Tc = &dict_Unsigned32;
 </pre>
 
 <p>
-For a connecting transport, the RFC 3588 Tc timer, in milliseconds.
+For a connecting transport, the &the_rfc; Tc timer, in milliseconds.
 Note that this timer determines the frequency with which a transport
 will attempt to establish a connection with its peer only <em>before</em>
 an initial connection is established: once there is an initial
@@ -1125,7 +1129,7 @@ its transports.</p>
 <type>
 <v>SvcName = &service_name;</v>
 <v>App = &application_alias;</v>
-<v>Request = &app_message;</v>
+<v>Request = &codec_message;</v>
 <v>Answer = term()</v>
 <v>Opt = &call_opt;</v>
 </type>
@@ -1618,7 +1622,7 @@ Return the list of started services.</p>
 Return a value for a Session-Id AVP.</p>
 
 <p>
-The value has the form required by section 8.8 of RFC 3588.
+The value has the form required by section 8.8 of &the_rfc;.
 Ident should be the Origin-Host of the peer from which
 the message containing the returned value will be sent.</p>
 
diff --git a/lib/diameter/doc/src/diameter_app.xml b/lib/diameter/doc/src/diameter_app.xml
index 304c69ebda..f4db625c71 100644
--- a/lib/diameter/doc/src/diameter_app.xml
+++ b/lib/diameter/doc/src/diameter_app.xml
@@ -1,5 +1,8 @@
 <?xml version="1.0" encoding="latin1" ?>
 <!DOCTYPE erlref SYSTEM "erlref.dtd" [
+  <!ENTITY message '<seealso marker="#message">message()</seealso>'>
+  <!ENTITY dict
+  '<seealso marker="diameter_dict#MESSAGE_RECORDS">diameter_dict(4)</seealso>'>
   <!ENTITY % also SYSTEM "seealso.ent" >
   <!ENTITY % here SYSTEM "seehere.ent" >
   %also;
@@ -124,39 +127,17 @@ mandatory values as the bare value.</p>
 
 <marker id="message"/>
 
-<tag><c>message() = record() | list()</c></tag>
+<tag><c>message() = &codec_message;</c></tag>
 <item>
 <p>
 The representation of a Diameter message as passed to
-&mod_call;.
-The record representation is as outlined in
-<seealso
-marker="diameter_dict#MESSAGE_RECORDS">diameter_dict(4)</seealso>:
-a message as defined in a dictionary file is encoded as a record with
-one field for each component AVP.
-Equivalently, a message can also be encoded as a list whose head is
-the atom-valued message name (the record name minus any
-prefix specified in the relevant dictionary file) and whose tail is a
-list of <c>{FieldName, FieldValue}</c> pairs.</p>
-
-<p>
-A third representation allows a message to be specified as a list
-whose head is a <c>#diameter_header{}</c> record and whose tail is a list
-of <c>#diameter_avp{}</c> records.
-This representation is used by diameter itself when relaying requests
-as directed by the return value of a
-&handle_request;
-callback.
-It differs from the other other two in that it bypasses the checks for
-messages that do not agree with their definitions in the dictionary in
-question (since relays agents must handle arbitrary request): messages
-are sent exactly as specified.</p>
+&mod_call; or returned from a &handle_request; callback.</p>
 
 </item>
 
 <marker id="packet"/>
 
-<tag><c>packet() = #diameter_packet{}</c></tag>
+<tag><c>packet() = &codec_packet;</c></tag>
 <item>
 <p>
 A container for incoming and outgoing Diameter messages that's passed
@@ -505,8 +486,7 @@ The application in which the callback takes place (that is, the
 callback module as configured with &mod_start_service;)
 is determined by the Application Identifier in the header of the
 incoming request message, the selected module being the one
-whose corresponding <seealso
-marker="diameter_dict#MESSAGE_RECORDS">dictionary</seealso> declares
+whose corresponding dictionary declares
 itself as defining either the application in question or the Relay
 application.</p>
 
@@ -526,8 +506,7 @@ The argument &packet; has the following signature.</p>
 The <c>msg</c> field will be <c>undefined</c> in case the request has
 been received in the relay application.
 Otherwise it contains the record representing the request as outlined
-in <seealso
-marker="diameter_dict#MESSAGE_RECORDS">diameter_dict(4)</seealso>.</p>
+in &dict;.</p>
 
 <p>
 The <c>errors</c> field specifies any Result-Code's identifying errors
@@ -579,7 +558,7 @@ where <c>Avps</c> sets the Origin-Host, Origin-Realm, the specified
 Result-Code and (if the request sent one) Session-Id AVP's.</p>
 
 <p>
-Note that RFC 3588 mandates that only answers with a 3xxx series
+Note that &the_rfc; mandates that only answers with a 3xxx series
 Result-Code (protocol errors) may set the E bit.
 Returning a non-3xxx value in a <c>protocol_error</c> tuple
 will cause the request process in question to fail.</p>
diff --git a/lib/diameter/doc/src/diameter_codec.xml b/lib/diameter/doc/src/diameter_codec.xml
new file mode 100644
index 0000000000..4a77d5435b
--- /dev/null
+++ b/lib/diameter/doc/src/diameter_codec.xml
@@ -0,0 +1,389 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE erlref SYSTEM "erlref.dtd" [
+  <!ENTITY records
+  '<seealso marker="diameter_dict#MESSAGE_RECORDS">diameter_dict(4)</seealso>'>
+  <!ENTITY types
+  '<seealso marker="diameter_dict#DATA_TYPES">diameter_dict(4)</seealso>'>
+  <!ENTITY % also SYSTEM "seealso.ent" >
+  <!ENTITY % here SYSTEM "seehere.ent" >
+  %also;
+  %here;
+]>
+
+<erlref>
+<header>
+<copyright>
+<year>2012</year>
+<holder>Ericsson AB. All Rights Reserved.</holder>
+</copyright>
+<legalnotice>
+The contents of this file are subject to the Erlang Public License,
+Version 1.1, (the "License"); you may not use this file except in
+compliance with the License. You should have received a copy of the
+Erlang Public License along with this software. If not, it can be
+retrieved online at http://www.erlang.org/.
+
+Software distributed under the License is distributed on an "AS IS"
+basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+the License for the specific language governing rights and limitations
+under the License.
+
+</legalnotice>
+
+<title>diameter_codec(3)</title>
+<prepared>Anders Svensson</prepared>
+<responsible></responsible>
+<docno></docno>
+<approved></approved>
+<checked></checked>
+<date></date>
+<rev></rev>
+<file>diameter_codec.xml</file>
+</header>
+
+<module>diameter_codec</module>
+<modulesummary>Decode and encode of Diameter messages.</modulesummary>
+
+<description>
+
+<p>
+Incoming Diameter messages are decoded from binary() before being
+communicated to &man_app; callbacks.
+Similarly, outgoing Diameter messages are encoded into binary() before
+being passed to the appropriate &man_transport; module for
+transmission.
+The functions in this module implement this encode/decode.</p>
+
+<note>
+<p>
+Calls to this module are made by diameter itself as a consequence of
+configuration passed to &mod_start_service;.
+The encode/decode functions may also be useful for other purposes (eg.
+test) but the diameter user does not need to call them explicitly when
+sending and receiving messages using &mod_call; and the callback
+interface documented in &man_app;.</p>
+</note>
+
+<p>
+The &header; and &packet; records below
+are defined in diameter.hrl, which can be included as follows.</p>
+
+<pre>
+-include_lib("diameter/include/diameter.hrl").
+</pre>
+
+<p>
+Application-specific records are definied in the hrl
+files resulting from dictionary file compilation.</p>
+
+</description>
+
+<!-- ===================================================================== -->
+
+<section>
+<title>DATA TYPES</title>
+
+<p></p>
+
+<taglist>
+
+<marker id="integers"/>
+
+<tag><c>uint8()&nbsp; = 0..255</c></tag>
+<tag><c>uint24() = 0..16777215</c></tag>
+<tag><c>uint32() = 0..4294967295</c></tag>
+<item>
+<p>
+8-bit, 24-bit and 32-bit integers occurring in Diameter and AVP
+headers.</p>
+</item>
+
+<marker id="avp"/>
+
+<tag><c>avp() = #diameter_avp{}</c></tag>
+<item>
+<p>
+The application-neutral representation of an AVP.
+Primarily intended for use by relay applications that need to handle
+arbitrary Diameter applications.
+A service implementing a specific Diameter application
+(for which it configures a dictionary) can manipulate values of type
+&message; instead.</p>
+
+<p>
+Fields have the following types.</p>
+
+<taglist>
+
+<tag><c>code = uint32()</c></tag>
+<tag><c>is_mandatory = boolean()</c></tag>
+<tag><c>need_encryption = boolean()</c></tag>
+<tag><c>vendor_id = uint32() | undefined</c></tag>
+<item>
+<p>
+Values in the AVP header, corresponding to AVP Code, the M flag, P
+flags and Vendor-ID respectivelty.
+A Vendor-ID other than <c>undefined</c> implies a set V flag.</p>
+</item>
+
+<tag><c>data = iolist()</c></tag>
+<item>
+<p>
+The data bytes of the AVP.</p>
+</item>
+
+<tag><c>name = atom()</c></tag>
+<item>
+<p>
+The name of the AVP as defined in the dictionary file in question, or
+<c>undefined</c> if the AVP is unknown to the dictionary file in
+question.</p>
+</item>
+
+<tag><c>value = term()</c></tag>
+<item>
+<p>
+The decoded value of an AVP.
+Will be <c>undefined</c> on decode if the data bytes could
+not be decoded or the AVP is unknown.
+The type of a decoded value is as document in &types;.</p>
+</item>
+
+<tag><c>type = atom()</c></tag>
+<item>
+<p>
+The type of the AVP as specified in the dictionary file in question
+(or one it inherits).
+Possible types are <c>undefined</c> and the Diameter types:
+<c>OctetString</c>, <c>Integer32</c>, <c>Integer64</c>,
+<c>Unsigned32</c>, <c>Unsigned64</c>, <c>Float32</c>, <c>Float64</c>,
+<c>Grouped</c>, <c>Enumerated</c>, <c>Address</c>, <c>Time</c>,
+<c>UTF8String</c>, <c>DiameterIdentity</c>, <c>DiameterURI</c>,
+<c>IPFilterRule</c> and <c>QoSFilterRule</c>.</p>
+</item>
+
+</taglist>
+
+</item>
+
+<marker id="dictionary"/>
+
+<tag><c>dictionary() = module()</c></tag>
+<item>
+
+<p>
+The name of a generated dictionary module as generated by &man_compile;
+or &make_codec;.
+The interface provided by a dictionary module is an
+implementation detail that may change.</p>
+</item>
+
+<marker id="header"/>
+
+<tag><c>header() = #diameter_header{}</c></tag>
+<item>
+<p>
+The record representation of the Diameter header.
+Values in a &packet; returned by &decode; are as extracted from the
+incoming message.
+Values set in an &packet; passed to &encode; are preserved in the
+encoded binary(), with the exception of <c>length</c>, <c>cmd_code</c>
+and <c>application_id</c>, all of which are determined by the
+&dictionary; in question.</p>
+
+<note>
+<p>
+It is not necessary to set header fields explicitly in outgoing
+messages as diameter itself will set appropriate values.
+Setting inappropriate values can be useful for test purposes.</p>
+</note>
+
+<p>
+Fields have the following types.</p>
+
+<taglist>
+
+<tag><c>version = uint8()</c></tag>
+<tag><c>length = uint24()</c></tag>
+<tag><c>cmd_code = uint24()</c></tag>
+<tag><c>application_id = uint32()</c></tag>
+<tag><c>hop_by_hop_id = uint32()</c></tag>
+<tag><c>end_to_end_id = uint32()</c></tag>
+<item>
+<p>
+Values of the Version, Message Length, Command-Code, Application-ID,
+Hop-by-Hop Identifier and End-to-End Identifier fields of the Diameter
+header.</p>
+</item>
+
+<tag><c>is_request = boolean()</c></tag>
+<tag><c>is_proxiable = boolean()</c></tag>
+<tag><c>is_error = boolean()</c></tag>
+<tag><c>is_retransmitted = boolean()</c></tag>
+<item>
+<p>
+Values correspoding to the R(equest), P(roxiable), E(rror)
+and T(Potentially re-transmitted message) flags of the Diameter
+header.</p>
+</item>
+
+</taglist>
+
+</item>
+
+<marker id="message"/>
+
+<tag><c>message() = record() | list()</c></tag>
+<item>
+<p>
+The representation of a Diameter message as passed to
+&mod_call; or returned from a &app_handle_request; callback.
+The record representation is as outlined in &records;:
+a message as defined in a dictionary file is encoded as a record with
+one field for each component AVP.
+Equivalently, a message can also be encoded as a list whose head is
+the atom-valued message name (as specified in the relevant dictionary
+file) and whose tail is a list of <c>{AvpName, AvpValue}</c> pairs.</p>
+
+<p>
+Another list-valued representation allows a message to be specified
+as a list whose head is a &header; and whose tail is an &avp; list.
+This representation is used by diameter itself when relaying requests
+as directed by the return value of a &app_handle_request; callback.
+It differs from the other other two in that it bypasses the checks for
+messages that do not agree with their definitions in the dictionary in
+question: messages are sent exactly as specified.</p>
+
+</item>
+
+<marker id="packet"/>
+
+<tag><c>packet() = #diameter_packet{}</c></tag>
+<item>
+<p>
+A container for incoming and outgoing Diameter messages.
+Fields have the following types.</p>
+
+<taglist>
+
+<tag><c>header = &header; | undefined</c></tag>
+<item>
+<p>
+The Diameter header of the message.
+Can be (and typically should be) <c>undefined</c> for an outgoing
+message in a non-relay application, in which case diameter provides
+appropriate values.</p>
+</item>
+
+<tag><c>avps = [&avp;] | undefined</c></tag>
+<item>
+<p>
+The AVPs of the message.
+Ignored for an outgoing message if the <c>msg</c> field is set to a
+value other than <c>undefined</c>.</p>
+</item>
+
+<tag><c>msg = &message; | undefined</c></tag>
+<item>
+<p>
+The incoming/outgoing message.
+For an incoming message, a record if the message can be
+decoded in a non-relay application, <c>undefined</c> otherwise.
+For an outgoing message, setting a <c>[&header; | &avp;]</c> list is
+equivalent to setting the <c>header</c> and <c>avps</c> fields to the
+corresponding values.</p>
+
+<warning>
+<p>
+A record-valued <c>msg</c> field does <b>not</b> imply an absence of
+decode errors.
+The <c>errors</c> field should also be examined.</p>
+</warning>
+
+</item>
+
+<tag><c>bin = binary()</c></tag>
+<item>
+<p>
+The incoming message prior to encode or the outgoing message after
+encode.</p>
+</item>
+
+<tag><c>errors = [5000..5999 | {5000..5999, avp()}]</c></tag>
+<item>
+<p>
+Errors detected at decode of an incoming message, as identified by
+a corresponding 5xxx series Result-Code (Permanent Failures).
+For an incoming request, these should be used to formulate an
+appropriate answer as documented for the &app_handle_request;
+callback in &man_app;.
+For an incoming answer, the &mod_application_opt;
+<c>answer_errors</c> determines the behaviour.</p>
+</item>
+
+<tag><c>transport_data = term()</c></tag>
+<item>
+<p>
+An arbitrary term of meaning only to the transport process in
+question, as documented in &man_transport;.</p>
+</item>
+
+</taglist>
+
+</item>
+
+</taglist>
+
+</section>
+
+<!-- ===================================================================== -->
+
+<funcs>
+
+<func>
+<name>decode(Mod, Bin) -> Pkt</name>
+<fsummary>Decode a Diameter message.</fsummary>
+<type>
+<v>Mod = &dictionary;</v>
+<v>Bin = binary()</v>
+<v>Pkt = &packet;</v>
+</type>
+<desc>
+
+<p>
+Decode a Diameter message.</p>
+
+</desc>
+</func>
+
+<func>
+<name>encode(Mod, Msg) -> Pkt</name>
+<fsummary>Encode a Diameter message.</fsummary>
+<type>
+<v>Mod = &dictionary;</v>
+<v>Msg = &message; | &packet;</v>
+<v>Pkt = &packet;</v>
+</type>
+<desc>
+
+<p>
+Encode a Diameter message.
+</p>
+
+</desc>
+</func>
+
+</funcs>
+
+<!-- ===================================================================== -->
+<!-- ===================================================================== -->
+
+<section>
+<title>SEE ALSO</title>
+
+<p>
+&man_compile;, &man_app;, &man_dict;, &man_make;</p>
+
+</section>
+
+</erlref>
diff --git a/lib/diameter/doc/src/diameter_compile.xml b/lib/diameter/doc/src/diameter_compile.xml
index eb6de80c11..0bd7ad1789 100644
--- a/lib/diameter/doc/src/diameter_compile.xml
+++ b/lib/diameter/doc/src/diameter_compile.xml
@@ -1,5 +1,7 @@
 <?xml version="1.0" encoding="iso-8859-1" ?>
 <!DOCTYPE comref SYSTEM "comref.dtd" [
+  <!ENTITY dictionary
+  '<seealso marker="diameter_dict">dictionary file</seealso>'>
   <!ENTITY % also SYSTEM "seealso.ent" >
   <!ENTITY % here SYSTEM "seehere.ent" >
   %also;
@@ -36,12 +38,14 @@ supplied.
 <description>
 
 <p>
-The diameterc utility is used to compile diameter
-<seealso marker="diameter_dict">dictionary files</seealso>
-into Erlang source.
-The resulting source implements the interface diameter requires
+The diameterc utility is used to compile a diameter
+&dictionary; into Erlang source.
+The resulting source implements the interface diameter required
 to encode and decode the dictionary's messages and AVP's.</p>
 
+<p>
+The module &man_make; provides an alternate compilation interface.</p>
+
 </description>
 
 <section>
@@ -52,53 +56,52 @@ to encode and decode the dictionary's messages and AVP's.</p>
 <tag><![CDATA[diameterc [<options>] <file>]]></tag>
 <item>
 <p>
-Compiles a single dictionary file. Valid options are as follows.</p>
-
-<!-- Leave -h/d/v undocumented, except for the usage message from the
-     utility itself. -->
-
-<taglist>
-<tag><![CDATA[-o <dir>]]></tag>
-<item>
-<p>
-Specifies the directory into which the generated source should be written.
-Defaults to the current working directory.</p>
-</item>
+Compile a single dictionary file to Erlang source.
+Valid options are as follows.</p>
 
 <tag><![CDATA[-i <dir>]]></tag>
 <item>
 <p>
-Specifies a directory to add to the code path.
+Prepend the specified directory to the code path.
 Use to point at beam files compiled from inherited dictionaries,
-<c>@inherits</c> in a dictionary file creating a beam dependency, not
-an erl/hrl dependency.</p>
+<c>&dict_inherits;</c> in a dictionary file creating a beam
+dependency, not an erl/hrl dependency.</p>
 
 <p>
 Multiple <c>-i</c> options can be specified.</p>
 </item>
 
+<taglist>
+<tag><![CDATA[-o <dir>]]></tag>
+<item>
+<p>
+Write generated source to the specified directory.
+Defaults to the current working directory.</p>
+</item>
+
 <tag><![CDATA[-E]]></tag>
 <tag><![CDATA[-H]]></tag>
 <item>
 <p>
-Supresses erl and hrl generation, respectively.</p>
+Supress erl and hrl generation, respectively.</p>
 </item>
 
 <tag><![CDATA[--name <name>]]></tag>
 <tag><![CDATA[--prefix <prefix>]]></tag>
 <item>
 <p>
-Set <c>@name</c> and <c>@prefix</c> in the dictionary,
-respectively.
+Set <c>&dict_name;</c> or <c>&dict_prefix;</c> to the specified
+string.
 Overrides any setting in the file itself.</p>
 </item>
 
 <tag><![CDATA[--inherits <dict>]]></tag>
 <item>
 <p>
-Append an <c>@inherits</c> to the dictionary before compiling.
-Specifying <c>'-'</c> as the dictionary has the effect of clearing any
-previous inherits, causing them to be ignored.</p>
+Append &dict_inherits; of the specified module.
+Specifying <c>"-"</c> has the effect of discarding clearing any
+previous inherits, both in the dictionary file and on the options
+list.</p>
 
 <p>
 Multiple <c>--inherits</c> options can be specified.</p>
@@ -127,7 +130,7 @@ Returns 0 on success, non-zero on failure.</p>
 <title>SEE ALSO</title>
 
 <p>
-&man_dict;</p>
+&man_make;, &man_dict;</p>
 
 </section>
 
diff --git a/lib/diameter/doc/src/diameter_dict.xml b/lib/diameter/doc/src/diameter_dict.xml
index 4a6cccc276..8b0687a22e 100644
--- a/lib/diameter/doc/src/diameter_dict.xml
+++ b/lib/diameter/doc/src/diameter_dict.xml
@@ -1,5 +1,11 @@
 <?xml version="1.0" encoding="latin1" ?>
 <!DOCTYPE erlref SYSTEM "fileref.dtd" [
+  <!ENTITY format
+           '<seealso marker="#FILE_FORMAT">FILE FORMAT</seealso>'>
+  <!ENTITY records
+           '<seealso marker="#MESSAGE_RECORDS">MESSAGE RECORDS</seealso>'>
+  <!ENTITY types
+           '<seealso marker="#DATA_TYPES">DATA TYPES</seealso>'>
   <!ENTITY % also SYSTEM "seealso.ent" >
   <!ENTITY % here SYSTEM "seehere.ent" >
   %also;
@@ -45,34 +51,33 @@ under the License.
 
 <description>
 <p>
-A diameter service as configured with &mod_start_service;
+A diameter service, as configured with &mod_start_service;,
 specifies one or more supported Diameter applications.
 Each Diameter application specifies a dictionary module that knows how
 to encode and decode its messages and AVPs.
 The dictionary module is in turn generated from a file that defines
 these messages and AVPs.
-The format of such a file is defined in
-<seealso marker="#FILE_FORMAT">FILE FORMAT</seealso> below.
+The format of such a file is defined in &format; below.
 Users add support for their specific applications by creating
 dictionary files, compiling them to Erlang modules using
-<seealso marker="diameterc">diameterc</seealso> and configuring the
+either &man_compile; or &man_make; and configuring the
 resulting dictionaries modules on a service.</p>
 
 <p>
-The codec generation also results in a hrl file that defines records
-for the messages and grouped AVPs defined for the application, these
-records being what a user of the diameter application sends and receives.
-(Modulo other available formats as discussed in &man_app;.)
+Dictionary module generation also results in a hrl file that defines
+records for the messages and Grouped AVPs defined by the
+dictionary, these records being what a user of the diameter
+application sends and receives, modulo other possible formats as
+discussed in &man_app;.
 These records and the underlying Erlang data types corresponding to
-Diameter data formats are discussed in <seealso
-marker="#MESSAGE_RECORDS">MESSAGE RECORDS</seealso> and <seealso
-marker="#DATA_TYPES">DATA TYPES</seealso> respectively.
-The generated hrl also contains defines for the possible values of
+Diameter data formats are discussed in &records; and &types;
+respectively.
+The generated hrl also contains macro definitions for the possible values of
 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
@@ -111,6 +116,8 @@ The order in which sections are specified is unimportant.</p>
 
 <taglist>
 
+<marker id="id"/>
+
 <tag><c>@id Number</c></tag>
 <item>
 <p>
@@ -134,6 +141,8 @@ Example:</p>
 
 </item>
 
+<marker id="name"/>
+
 <tag><c>@name Mod</c></tag>
 <item>
 <p>
@@ -155,6 +164,8 @@ Example:</p>
 
 </item>
 
+<marker id="prefix"/>
+
 <tag><c>@prefix Name</c></tag>
 <item>
 <p>
@@ -178,6 +189,8 @@ Example:</p>
 
 </item>
 
+<marker id="vendor"/>
+
 <tag><c>@vendor Number Name</c></tag>
 <item>
 <p>
@@ -198,6 +211,8 @@ Example:</p>
 
 </item>
 
+<marker id="avp_vendor_id"/>
+
 <tag><c>@avp_vendor_id Number</c></tag>
 <item>
 <p>
@@ -218,6 +233,8 @@ Region-Set
 
 </item>
 
+<marker id="inherits"/>
+
 <tag><c>@inherits Mod</c></tag>
 <item>
 <p>
@@ -241,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>
@@ -253,6 +270,8 @@ Example:</p>
 
 </item>
 
+<marker id="avp_types"/>
+
 <tag><c>@avp_types</c></tag>
 <item>
 <p>
@@ -263,7 +282,7 @@ The section consists of definitions of the form</p>
 
 <p>
 where Code is the integer AVP code, Type identifies an AVP Data Format
-as defined in <seealso marker="#DATA_TYPES">DATA TYPES</seealso> below,
+as defined in section &types; below,
 and Flags is a string of V, M and P characters indicating the flags to be
 set on an outgoing AVP or a single <c>'-'</c> (minus) character if
 none are to be set.</p>
@@ -280,13 +299,13 @@ 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>
 
+<marker id="custom_types"/>
+
 <tag><c>@custom_types Mod</c></tag>
 <item>
 <p>
@@ -308,6 +327,8 @@ Framed-IP-Address
 </pre>
 </item>
 
+<marker id="codecs"/>
+
 <tag><c>@codecs Mod</c></tag>
 <item>
 <p>
@@ -325,12 +346,14 @@ Framed-IP-Address
 </pre>
 </item>
 
+<marker id="messages"/>
+
 <tag><c>@messages</c></tag>
 <item>
 <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>
@@ -370,13 +393,15 @@ RTA ::= &lt; Diameter Header: 287, PXY >
 
 </item>
 
+<marker id="grouped"/>
+
 <tag><c>@grouped</c></tag>
 <item>
 <p>
 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>
@@ -395,6 +420,8 @@ Specifying a Vendor-Id in the definition of a grouped AVP is
 equivalent to specifying it with <c>@avp_vendor_id</c>.</p>
 </item>
 
+<marker id="enum"/>
+
 <tag><c>@enum Name</c></tag>
 <item>
 <p>
@@ -421,6 +448,8 @@ REMOVE_SIP_SERVER        3
 </pre>
 </item>
 
+<marker id="end"/>
+
 <tag><c>@end</c></tag>
 <item>
 <p>
@@ -447,8 +476,8 @@ The hrl generated from a dictionary specification defines records for the
 messages and grouped AVPs defined in <c>@messages</c> and
 <c>@grouped</c> sections.
 For each message or grouped AVP definition, a record is defined whose
-name is the message or AVP name prefixed with any dictionary prefix
-defined with <c>@prefix</c> and whose fields are the names of the AVPs
+name is the message or AVP name, prefixed with any dictionary prefix
+defined with <c>@prefix</c>, and whose fields are the names of the AVPs
 contained in the message or grouped AVP in the order specified in the
 definition in question.
 For example, the grouped AVP</p>
@@ -476,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"/>
@@ -489,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
@@ -564,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>
 
@@ -609,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"/>
@@ -640,7 +669,7 @@ Values of these types are not currently parsed by diameter.</p>
 <title>SEE ALSO</title>
 
 <p>
-&man_compile;, &man_main;, &man_app;</p>
+&man_compile;, &man_main;, &man_app;, &man_codec;, &man_make;</p>
 
 </section>
 
diff --git a/lib/diameter/doc/src/diameter_intro.xml b/lib/diameter/doc/src/diameter_intro.xml
index bc2afbd453..fd578ccf45 100644
--- a/lib/diameter/doc/src/diameter_intro.xml
+++ b/lib/diameter/doc/src/diameter_intro.xml
@@ -1,5 +1,8 @@
 <?xml version="1.0" encoding="latin1" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
+<!DOCTYPE chapter SYSTEM "chapter.dtd" [
+  <!ENTITY % also SYSTEM "seealso.ent">
+  %also;
+]>
 
 <chapter>
 <header>
@@ -35,7 +38,7 @@ under the License.
 
 <p>
 The diameter application is an implementation of the Diameter protocol
-as defined by RFC 3588.
+as defined by &the_rfc;.
 It supports arbitrary Diameter applications by way of a
 <em>dictionary</em> interface that allows messages and AVP's to be
 defined and input into diameter as configuration.
@@ -86,9 +89,9 @@ dictionary module
 that provide encode/decode functionality for outgoing/incoming
 Diameter messages belonging to the application.
 A dictionary module is generated from a <seealso
-marker="diameter_dict">specification file</seealso> using the <seealso
+marker="diameter_dict">dictionary file</seealso> using the <seealso
 marker="diameterc">diameterc</seealso> utility.
-Dictionaries for the RFC 3588 Diameter Common Messages, Base
+Dictionaries for the &the_rfc; Diameter Common Messages, Base
 Accounting and Relay applications are provided with the diameter
 application.</p>
 
diff --git a/lib/diameter/doc/src/diameter_make.xml b/lib/diameter/doc/src/diameter_make.xml
new file mode 100644
index 0000000000..da6124310e
--- /dev/null
+++ b/lib/diameter/doc/src/diameter_make.xml
@@ -0,0 +1,144 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE erlref SYSTEM "erlref.dtd" [
+  <!ENTITY filename
+  '<seealso marker="kernel:file#type-name">file:name()</seealso>'>
+  <!ENTITY dictionary
+  '<seealso marker="diameter_dict">dictionary file</seealso>'>
+  <!ENTITY % also SYSTEM "seealso.ent" >
+  <!ENTITY % here SYSTEM "seehere.ent" >
+  %also;
+  %here;
+]>
+
+<erlref>
+<header>
+<copyright>
+<year>2012</year>
+<holder>Ericsson AB. All Rights Reserved.</holder>
+</copyright>
+<legalnotice>
+The contents of this file are subject to the Erlang Public License,
+Version 1.1, (the "License"); you may not use this file except in
+compliance with the License. You should have received a copy of the
+Erlang Public License along with this software. If not, it can be
+retrieved online at http://www.erlang.org/.
+
+Software distributed under the License is distributed on an "AS IS"
+basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+the License for the specific language governing rights and limitations
+under the License.
+
+</legalnotice>
+
+<title>diameter_make(3)</title>
+<prepared>Anders Svensson</prepared>
+<responsible></responsible>
+<docno></docno>
+<approved></approved>
+<checked></checked>
+<date></date>
+<rev></rev>
+<file>diameter_make.xml</file>
+</header>
+
+<module>diameter_make</module>
+<modulesummary>Diameter dictionary compilation.</modulesummary>
+
+<description>
+
+<p>
+The function &codec; is used to compile a diameter
+&dictionary; into Erlang source.
+The resulting source implements the interface diameter required
+to encode and decode the dictionary's messages and AVP's.</p>
+
+<p>
+The utility &man_compile; provides an alternate compilation
+interface.</p>
+
+</description>
+
+<!-- ===================================================================== -->
+
+<funcs>
+
+<func>
+<name>codec(Path::string(), [Opt]) -> ok | {error, Reason}</name>
+<fsummary>Compile a dictionary file into Erlang source.</fsummary>
+<desc>
+
+<p>
+Compile a single dictionary file to Erlang source.
+<c>Opt</c> can have the following types.</p>
+
+<taglist>
+
+<tag><c>{include, Dir::string()}</c></tag>
+<item>
+<p>
+Prepend the specified directory to the code path.
+Use to point at beam files compiled from inherited dictionaries,
+<c>&dict_inherits;</c> in a dictionary file creating a beam
+dependency, not an erl/hrl dependency.</p>
+
+<p>
+Multiple <c>include</c> options can be specified.</p>
+</item>
+
+<tag><c>{outdir, Dir::string()}</c></tag>
+<item>
+<p>
+Write generated source to the specified directory.
+Defaults to the current working directory.</p>
+</item>
+
+<tag><c>{name|prefix, string()}</c></tag>
+<item>
+<p>
+Set <c>&dict_name;</c> or <c>&dict_prefix;</c> to the specified
+string.
+Overrides any setting in the file itself.</p>
+</item>
+
+<tag><c>{inherits, Mod::string()}</c></tag>
+<item>
+<p>
+Append &dict_inherits; of the specified module.
+Specifying <c>"-"</c> has the effect of discarding clearing any
+previous inherits, both in the dictionary file and on the options
+list.</p>
+
+<p>
+Multiple <c>inherits</c> options can be specified.</p>
+</item>
+
+</taglist>
+
+</desc>
+</func>
+
+</funcs>
+
+<!-- ===================================================================== -->
+
+<section>
+<title>BUGS</title>
+
+<p>
+All options are string-valued.
+In particular, it is not currently possible to
+an &dict_inherits; module as an atom() or a path as a &filename;</p>
+
+</section>
+
+<!-- ===================================================================== -->
+
+<section>
+<title>SEE ALSO</title>
+
+<p>
+&man_compile;, &man_dict;</p>
+
+</section>
+
+</erlref>
diff --git a/lib/diameter/doc/src/diameter_sctp.xml b/lib/diameter/doc/src/diameter_sctp.xml
index a023a9bc08..5e3fd5eaf1 100644
--- a/lib/diameter/doc/src/diameter_sctp.xml
+++ b/lib/diameter/doc/src/diameter_sctp.xml
@@ -1,5 +1,11 @@
 <?xml version="1.0" encoding="latin1" ?>
 <!DOCTYPE erlref SYSTEM "erlref.dtd" [
+  <!ENTITY gen_sctp '<seealso marker="kernel:gen_sctp">gen_sctp(3)</seealso>'>
+  <!ENTITY gen_sctp_open1
+  '<seealso marker="kernel:gen_sctp#open-1">gen_sctp:open/1</seealso>'>
+  <!ENTITY ip_address
+  '<seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso>'>
+  <!ENTITY inet '<seealso marker="kernel:inet">inet(3)</seealso>'>
   <!ENTITY % also SYSTEM "seealso.ent" >
   <!ENTITY % here SYSTEM "seehere.ent" >
   %also;
@@ -43,8 +49,7 @@ under the License.
 <description>
 
 <p>
-This module implements diameter transport over SCTP using <seealso
-marker="kernel:gen_sctp">gen_sctp</seealso>.
+This module implements diameter transport over SCTP using &gen_sctp;.
 It can be specified as the value of a transport_module option to
 &mod_add_transport;
 and implements the behaviour documented in
@@ -65,9 +70,9 @@ and implements the behaviour documented in
 <v>Type = connect | accept</v>
 <v>Ref = &mod_transport_ref;</v>
 <v>Svc = #diameter_service{}</v>
-<v>Opt = {raddr, <seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso>} | {rport, integer()} | term()</v>
+<v>Opt = {raddr, &ip_address;} | {rport, integer()} | term()</v>
 <v>Pid = pid()</v>
-<v>LAddr = <seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso></v>
+<v>LAddr = &ip_address;</v>
 <v>Reason = term()</v>
 </type>
 <desc>
@@ -84,8 +89,7 @@ unspecified.
 More than one <c>raddr</c> option can be specified, in which case the
 connecting transport in question attempts each in sequence until
 an association is established.
-Remaining options are any accepted by <seealso
-marker="kernel:gen_sctp#open-1">gen_sctp:open/1</seealso>, with the exception
+Remaining options are any accepted by &gen_sctp_open1;, with the exception
 of options <c>mode</c>, <c>binary</c>, <c>list</c>, <c>active</c>
 and <c>sctp_events</c>.
 Note that options <c>ip</c> and <c>port</c> specify the local address
@@ -102,14 +106,12 @@ connecting transport.</p>
 <warning>
 <p>
 An insufficiently large receive buffer may result in a peer having to
-resend incoming messages: set the <seealso
-marker="kernel:inet">inet(3)</seealso> option <c>recbuf</c> to increase
+resend incoming messages: set the &inet; option <c>recbuf</c> to increase
 the buffer size.</p>
 
 <p>
 An insufficiently large send buffer may result in outgoing messages
-being discarded: set the <seealso
-marker="kernel:inet">inet(3)</seealso> option <c>sndbuf</c> to increase
+being discarded: set the &inet; option <c>sndbuf</c> to increase
 the buffer size.</p>
 </warning>
 
@@ -145,10 +147,7 @@ outbound streams.</p>
 <title>SEE ALSO</title>
 
 <p>
-&man_main;,
-&man_transport;,
-<seealso marker="kernel:gen_sctp">gen_sctp(3)</seealso>,
-<seealso marker="kernel:inet">inet(3)</seealso></p>
+&man_main;, &man_transport;, &gen_sctp;, &inet;</p>
 
 </section>
 
diff --git a/lib/diameter/doc/src/diameter_soc.xml b/lib/diameter/doc/src/diameter_soc.xml
index 6b9ef9f756..16f6b9d5bb 100644
--- a/lib/diameter/doc/src/diameter_soc.xml
+++ b/lib/diameter/doc/src/diameter_soc.xml
@@ -1,11 +1,15 @@
 <?xml version="1.0" encoding="latin1" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
+<!DOCTYPE chapter SYSTEM "chapter.dtd" [
+  <!ENTITY % also SYSTEM "seealso.ent" >
+  %also;
+]>
 
 <chapter>
 
 <header>
 <copyright>
 <year>2011</year>
+<year>2012</year>
 <holder>Ericsson AB. All Rights Reserved.</holder>
 </copyright>
 
@@ -41,38 +45,20 @@ Known points of questionable or non-compliance.</p>
 <!-- ===================================================================== -->
 
 <section>
-<title>RFC 3588</title>
+<title>&the_rfc;</title>
 
 <list>
 
 <item>
 <p>
-The End-to-End Security framework (section 2.9) isn't implemented
-since it is largely unspecified.
-The document that was to describe it
-(reference [AAACMS]) was abandoned in an uncompleted state several
-years ago and the current draft RFC deprecates the framework,
-including the P Flag in the AVP header.</p>
-</item>
-
-<item>
-<p>
-There is no TLS support over SCTP.
-RFC 3588 requires that a Diameter server support TLS but in
-practise this seems to mean TLS over SCTP since there are limitations
-with running over SCTP: see RFC 6083 (DTLS over SCTP), which is a
-response to RFC 3436 (TLS over SCTP).
-The current RFC 3588 draft acknowledges this by equating
-TLS with TLS/TCP and DTLS/SCTP but we do not yet support DTLS.</p>
+There is no support for DTLS over SCTP.</p>
 </item>
 
 <item>
 <p>
 There is no explicit support for peer discovery (section 5.2).
 It can possibly be implemented on top of diameter as is but this is
-probably something that diameter should do.
-The current draft deprecates portions of the original RFC's mechanisms
-however.</p>
+probably something that diameter should do.</p>
 </item>
 
 <item>
diff --git a/lib/diameter/doc/src/diameter_tcp.xml b/lib/diameter/doc/src/diameter_tcp.xml
index be8a938115..e3b8c733b7 100644
--- a/lib/diameter/doc/src/diameter_tcp.xml
+++ b/lib/diameter/doc/src/diameter_tcp.xml
@@ -1,5 +1,22 @@
 <?xml version="1.0" encoding="latin1" ?>
 <!DOCTYPE erlref SYSTEM "erlref.dtd" [
+  <!ENTITY gen_tcp_connect3
+  '<seealso marker="kernel:gen_tcp#connect-3">gen_tcp:connect/3</seealso>'>
+  <!ENTITY gen_tcp_listen2
+  '<seealso marker="kernel:gen_tcp#listen-2">gen_tcp:listen/2</seealso>'>
+  <!ENTITY ip_address
+  '<seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso>'>
+  <!ENTITY ssl_connect2
+  '<seealso marker="ssl:ssl#connect-2">ssl:connect/2</seealso>'>
+  <!ENTITY ssl_connect3
+  '<seealso marker="ssl:ssl#connect-3">ssl:connect/3</seealso>'>
+  <!ENTITY ssl_accept2
+  '<seealso marker="ssl:ssl#ssl_accept-2">ssl:ssl_accept/2</seealso>'>
+  <!ENTITY ssl_listen2
+  '<seealso marker="ssl:ssl#listen-2">ssl:listen/2</seealso>'>
+  <!ENTITY gen_tcp '<seealso marker="kernel:gen_tcp">gen_tcp(3)</seealso>'>
+  <!ENTITY inet '<seealso marker="kernel:inet">inet(3)</seealso>'>
+  <!ENTITY ssl '<seealso marker="ssl:ssl">ssl(3)</seealso>'>
   <!ENTITY % also SYSTEM "seealso.ent" >
   <!ENTITY % here SYSTEM "seehere.ent" >
   %also;
@@ -43,14 +60,13 @@ under the License.
 <description>
 
 <p>
-This module implements diameter transport over TCP using <seealso
-marker="kernel:gen_tcp">gen_tcp</seealso>.
+This module implements diameter transport over TCP using &gen_tcp;.
 It can be specified as the value of a <c>transport_module</c> option to
 &mod_add_transport;
 and implements the behaviour documented in
 &man_transport;.
 TLS security is supported, both as an upgrade following
-capabilities exchange as specified by RFC 3588 and
+capabilities exchange as specified by &the_rfc; and
 at connection establishment as in the current draft standard.</p>
 
 <p>
@@ -74,9 +90,9 @@ before configuring TLS capability on diameter transports.</p>
 <v>Svc = #diameter_service{}</v>
 <v>Opt = OwnOpt | SslOpt | TcpOpt</v>
 <v>Pid = pid()</v>
-<v>LAddr = <seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso></v>
+<v>LAddr = &ip_address;</v>
 <v>Reason = term()</v>
-<v>OwnOpt = {raddr, <seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso>}
+<v>OwnOpt = {raddr, &ip_address;}
           | {rport, integer()}
           | {port, integer()}</v>
 <v>SslOpt = {ssl_options, true | list()}</v>
@@ -95,16 +111,12 @@ transport.
 Option <c>ssl_options</c> must be specified for a transport
 that should support TLS: a value of <c>true</c> results in a
 TLS handshake immediately upon connection establishment while
-<c>list()</c> specifies options to be passed to <seealso
-marker="ssl:ssl#connect-2">ssl:connect/2</seealso> or
-<seealso marker="ssl:ssl#ssl_accept-2">ssl:ssl_accept/2</seealso>
+<c>list()</c> specifies options to be passed to &ssl_connect2; or
+&ssl_accept2;
 after capabilities exchange if TLS is negotiated.
-Remaining options are any accepted by <seealso
-marker="ssl:ssl#connect-3">ssl:connect/3</seealso> or <seealso
-marker="kernel:gen_tcp#connect-3">gen_tcp:connect/3</seealso> for
-a connecting transport, or <seealso
-marker="ssl:ssl#listen-2">ssl:listen/2</seealso> or <seealso
-marker="kernel:gen_tcp#listen-2">gen_tcp:listen/2</seealso> for
+Remaining options are any accepted by &ssl_connect3; or
+&gen_tcp_connect3; for
+a connecting transport, or &ssl_listen2; or &gen_tcp_listen2; for
 a listening transport, depending on whether or not <c>{ssl_options, true}</c>
 has been specified.
 Options <c>binary</c>,
@@ -150,11 +162,7 @@ The returned local address list has length one.</p>
 <title>SEE ALSO</title>
 
 <p>
-&man_main;,
-&man_transport;,
-<seealso marker="kernel:gen_tcp">gen_tcp(3)</seealso>,
-<seealso marker="kernel:inet">inet(3)</seealso>,
-<seealso marker="ssl:ssl">ssl(3)</seealso></p>
+&man_main;, &man_transport;, &gen_tcp;, &inet;, &ssl;</p>
 
 </section>
 
diff --git a/lib/diameter/doc/src/diameter_transport.xml b/lib/diameter/doc/src/diameter_transport.xml
index 0507af63a8..55b531155f 100644
--- a/lib/diameter/doc/src/diameter_transport.xml
+++ b/lib/diameter/doc/src/diameter_transport.xml
@@ -1,5 +1,8 @@
 <?xml version="1.0" encoding="latin1" ?>
 <!DOCTYPE erlref SYSTEM "erlref.dtd" [
+  <!ENTITY message '<seealso marker="#message">message()</seealso>'>
+  <!ENTITY ip_address
+  '<seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso>'>
   <!ENTITY % also SYSTEM "seealso.ent" >
   <!ENTITY % here SYSTEM "seehere.ent" >
   %also;
@@ -50,16 +53,49 @@ diameter starts a transport process and a message interface with which
 the transport process communicates with the process that starts it (aka its
 parent).</p>
 
-<marker id="start"/>
 </description>
 
 <!-- ===================================================================== -->
 
+<section>
+<title>DATA TYPES</title>
+
+<taglist>
+
+<marker id="message"/>
+
+<tag><c>message() = binary() | &codec_packet;</c></tag>
+<item>
+<p>
+A Diameter message as passed over the transport interface.</p>
+
+<p>
+For an inbound message from a transport process, a &codec_packet; must
+contain the received message in its <c>bin</c> field.
+In the case of an inbound request, any value set in the
+<c>transport_data</c> field will passed back to the transport module
+in the corresponding answer message, unless the sender supplies
+another value.</p>
+
+<p>
+For an outbound message to a transport process, a &codec_packet; has a
+value other than <c>undefined</c> in its <c>transport_data</c> field
+and has the binary() to send in its <c>bin</c> field.</p>
+</item>
+
+</taglist>
+
+</section>
+
+<!-- ===================================================================== -->
+
 <funcs>
 
 <func>
 <name>Mod:start({Type, Ref}, Svc, Config)
-         -> {ok, Pid} | {ok, Pid, LAddrs} | {error, Reason}</name>
+         -> {ok, Pid}
+          | {ok, Pid, LAddrs}
+          | {error, Reason}</name>
 <fsummary>Start a transport process.</fsummary>
 <type>
 <v>Type = connect | accept</v>
@@ -67,7 +103,7 @@ parent).</p>
 <v>Svc = #diameter_service{}</v>
 <v>Config = term()</v>
 <v>Pid = pid()</v>
-<v>LAddrs = [<seealso marker="kernel:inet#type-ip_address">inet:ip_address()</seealso>]</v>
+<v>LAddrs = [&ip_address;]</v>
 <v>Reason = term()</v>
 </type>
 <desc>
@@ -79,8 +115,8 @@ A transport process maintains a connection with a single remote peer.</p>
 
 <p>
 <c>Type</c> indicates whether the transport process in question
-is being started for a connecting (<c>connect</c>) or listening
-(<c>accept</c>) transport.
+is being started for a connecting (<c>Type=connect</c>) or listening
+(<c>Type=accept</c>) transport.
 In the latter case, transport processes are started as required to
 accept connections from multiple peers.</p>
 
@@ -90,13 +126,12 @@ that has lead to starting of a transport process.</p>
 
 <p>
 <c>Svc</c> contains the capabilities passed to &mod_start_service; and
-&mod_add_transport;,
-values passed to the latter overriding those passed to the former.</p>
+&mod_add_transport;, values passed to the latter overriding those
+passed to the former.</p>
 
 <p>
 <c>Config</c> is as passed in <c>transport_config</c> tuple in the
-&mod_transport_opt;
-list passed to &mod_add_transport;.</p>
+&mod_transport_opt; list passed to &mod_add_transport;.</p>
 
 <p>
 The start function should use the <c>Host-IP-Address</c> list and/or
@@ -114,13 +149,13 @@ it dies.
 It should not link to the parent.
 It should exit if its transport connection with its peer is lost.</p>
 
-<marker id="MESSAGES"/>
 </desc>
 </func>
 
 </funcs>
 
 <!-- ===================================================================== -->
+<marker id="MESSAGES"/>
 
 <section>
 <title>MESSAGES</title>
@@ -130,19 +165,15 @@ All messages sent over the transport interface are of the
 form <c>{diameter, term()}</c>.</p>
 
 <p>
-A transport process can expect the following messages from
-diameter.</p>
+A transport process can expect messages of the following types from
+its parent.</p>
 
 <taglist>
 
-<tag><c>{diameter, {send, Packet}}</c></tag>
+<tag><c>{diameter, {send, &message;}}</c></tag>
 <item>
 <p>
-An outbound Diameter message.
-<c>Packet</c> can be either binary() (the message to be sent)
-or a <c>#diameter_packet{}</c> record whose <c>transport_data</c>
-field contains a value other than undefined and whose <c>bin</c> field
-contains the binary to send.</p>
+An outbound Diameter message.</p>
 </item>
 
 <tag><c>{diameter, {close, Pid}}</c></tag>
@@ -185,7 +216,7 @@ TLS.</p>
 </taglist>
 
 <p>
-A transport process should send the following messages
+A transport process should send messages of the following types
 to its parent.</p>
 
 <taglist>
@@ -208,19 +239,10 @@ Not sent if the transport process has <c>Type=accept</c>.
 endpoint to which the transport has connected.</p>
 </item>
 
-<tag><c>{diameter, {recv, Packet}}</c></tag>
+<tag><c>{diameter, {recv, &message;}}</c></tag>
 <item>
 <p>
-An inbound Diameter message.
-<c>Packet</c> can be either binary() (the received message)
-or a <c>#diameter_packet{}</c> record
-whose <c>bin</c> field contains the received binary().
-Any value (other than <c>undefined</c>) set in
-the <c>transport_data</c> field will be passed back with a
-corresponding answer message in the case that the inbound message is a
-request unless the sender sets another value.
-How <c>transport_data</c> is used/interpreted is up to the
-transport module.</p>
+An inbound Diameter message.</p>
 </item>
 
 <tag><c>{diameter, {tls, Ref}}</c></tag>
diff --git a/lib/diameter/doc/src/files.mk b/lib/diameter/doc/src/files.mk
index 89ec1031e6..00ced3d91e 100644
--- a/lib/diameter/doc/src/files.mk
+++ b/lib/diameter/doc/src/files.mk
@@ -26,6 +26,8 @@ XML_REF1_FILES = \
 XML_REF3_FILES = \
 	diameter.xml \
 	diameter_app.xml \
+	diameter_codec.xml \
+	diameter_make.xml \
 	diameter_transport.xml \
 	diameter_tcp.xml \
 	diameter_sctp.xml
diff --git a/lib/diameter/doc/src/notes.xml b/lib/diameter/doc/src/notes.xml
index b89d84a4f6..d448b01eba 100644
--- a/lib/diameter/doc/src/notes.xml
+++ b/lib/diameter/doc/src/notes.xml
@@ -42,6 +42,163 @@ first.</p>
 
 <!-- ===================================================================== -->
 
+<section><title>Diameter 1.3</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+          <p>
+	    Fix faulty handling of Origin-State-Id and faulty config
+	    values.</p>
+          <p>
+	    The former was expected in a list despite the
+	    documentation requiring (correctly) an integer. A bare
+	    value for a list-valued capability was not handled.</p>
+          <p>
+	    Own Id: OTP-10440</p>
+        </item>
+        <item>
+          <p>
+	    Fix timing of up/down events.</p>
+          <p>
+	    Previously, a call to diameter:call/4 following a peer_up
+	    callback might incorrectly return {error, no_connection},
+	    depending on timing. Both events now follow the
+	    corresponding callbacks.</p>
+          <p>
+	    Own Id: OTP-10459</p>
+        </item>
+        <item>
+          <p>
+	    Make diameter:service_info/2 usable in peer_up, peer_down
+	    and pick_peer callbacks.</p>
+          <p>
+	    Except for in pick_peer when {call_mutates_state, false},
+	    it would previously hang indefinitely.</p>
+          <p>
+	    Own Id: OTP-10460</p>
+        </item>
+        <item>
+          <p>
+	    Verify that End-to-End and Hop-by-Hop Identifiers in an
+	    incoming CEA/DPA match those sent in the corresponding
+	    CER/DPR.</p>
+          <p>
+	    The values were previously ignored. Answers whose
+	    identifiers do not match are handled as unexpected.</p>
+          <p>
+	    Own Id: OTP-10565</p>
+        </item>
+        <item>
+          <p>
+	    Fix formatting problems in PDF documentation.</p>
+          <p>
+	    In particular, text corresponding to links in HTML was
+	    omitted in preformatted blocks. There are still issues
+	    with indentation but this is not diameter-specific.</p>
+          <p>
+	    Own Id: OTP-10583</p>
+        </item>
+      </list>
+    </section>
+
+
+    <section><title>Improvements and New Features</title>
+      <list>
+        <item>
+          <p>
+	    Let prepare_request, prepare_retransmit and
+	    handle_request callbacks return a function to be invoked
+	    on outgoing messages after encode.</p>
+          <p>
+	    This allows encoded messages to be logged for example.</p>
+          <p>
+	    Own Id: OTP-10441</p>
+        </item>
+        <item>
+          <p>
+	    Add service_opt() 'restrict_connections' to allow
+	    multiple transport connections with the same peer.</p>
+          <p>
+	    Own Id: OTP-10443</p>
+        </item>
+        <item>
+          <p>
+	    Add service_opt() 'sequence' to allow the masking of a
+	    constant onto the topmost bits of End-to-End and
+	    Hop-by-Hop identifiers.</p>
+          <p>
+	    This allows the same service on different nodes to use
+	    distinct values in outgoing request messages.</p>
+          <p>
+	    Own Id: OTP-10445</p>
+        </item>
+        <item>
+          <p>
+	    Add diameter:service_info(PeerRef) to return the
+	    transport_ref() and transport_opt() list of the
+	    corresponding transport.</p>
+          <p>
+	    This allows easy access to these from diameter_app
+	    callbacks that only get peer_ref() as an argument.</p>
+          <p>
+	    Own Id: OTP-10470</p>
+        </item>
+        <item>
+          <p>
+	    Add reference pages diameter_codec(3) and
+	    diameter_make(3).</p>
+          <p>
+	    Own Id: OTP-10471</p>
+        </item>
+        <item>
+          <p>
+	    Add events for service start and stop.</p>
+          <p>
+	    Own Id: OTP-10492</p>
+        </item>
+        <item>
+          <p>
+	    Add transport_opt() 'disconnect_cb' to make the sending
+	    of DPR configurable.</p>
+          <p>
+	    Whether or not DPR should be sent at application stop,
+	    service stop or transport removal is determined by the
+	    value returned by the callback, as is the
+	    Disconnect-Cause and timeout if DPA is not received.</p>
+          <p>
+	    Own Id: OTP-10493</p>
+        </item>
+        <item>
+          <p>
+	    Add transport_opt() 'capx_timeout' for the timeout
+	    associated with non-reception of CER/CEA.</p>
+          <p>
+	    Own Id: OTP-10554</p>
+        </item>
+        <item>
+          <p>
+	    Allow a handle_request callback to return a
+	    #diameter_packet{}.</p>
+          <p>
+	    This allows an answer to set transport_data and header
+	    fields.</p>
+          <p>
+	    Own Id: OTP-10566</p>
+        </item>
+        <item>
+          <p>
+	    Update documentation for RFC 6733.</p>
+          <p>
+	    RFC 3588 is now obsolete.</p>
+          <p>
+	    Own Id: OTP-10568</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
 <section><title>Diameter 1.2</title>
 
     <section><title>Fixed Bugs and Malfunctions</title>
@@ -428,7 +585,7 @@ Known issues or limitations:</p>
 Some agent-related functionality is not entirely complete.
 In particular, support for proxy agents, that advertise specific
 Diameter applications but otherwise relay messages in much the same
-way as relay agents (for which a &handle_request;
+way as relay agents (for which a handle_request
 callback can return a <c>relay</c> tuple), will be completed in an
 upcoming release.
 There may also be more explicit support for redirect agents, although
@@ -460,7 +617,7 @@ could likely be expanded upon.</p>
 
 <item>
 <p>
-The function &service_info;
+The function diameter:service_info/2
 can be used to retrieve information about a started service
 (statistics, information about connected peers, etc) but
 this is not yet documented and both the input and output may change
diff --git a/lib/diameter/doc/src/ref_man.xml b/lib/diameter/doc/src/ref_man.xml
index 137ce79094..4b99fe716d 100644
--- a/lib/diameter/doc/src/ref_man.xml
+++ b/lib/diameter/doc/src/ref_man.xml
@@ -6,6 +6,7 @@
 <header>
 <copyright>
 <year>2011</year>
+<year>2012</year>
 <holder>Ericsson AB. All Rights Reserved.</holder>
 </copyright>
 <legalnotice>
@@ -40,7 +41,9 @@ applications on top of the Diameter protocol. </p>
 <xi:include href="diameter.xml"/>
 <xi:include href="diameter_compile.xml"/>
 <xi:include href="diameter_app.xml"/>
+<xi:include href="diameter_codec.xml"/>
 <xi:include href="diameter_dict.xml"/>
+<xi:include href="diameter_make.xml"/>
 <xi:include href="diameter_transport.xml"/>
 <xi:include href="diameter_tcp.xml"/>
 <xi:include href="diameter_sctp.xml"/>
diff --git a/lib/diameter/doc/src/seealso.ent b/lib/diameter/doc/src/seealso.ent
index 6f67630220..4647c42f85 100644
--- a/lib/diameter/doc/src/seealso.ent
+++ b/lib/diameter/doc/src/seealso.ent
@@ -32,6 +32,8 @@ significant.
 
 -->
 
+<!ENTITY the_rfc 'RFC 6733'>
+
 <!-- diameter -->
 
 <!ENTITY mod_add_transport '<seealso marker="diameter#add_transport-2">diameter:add_transport/2</seealso>'>
@@ -77,12 +79,21 @@ significant.
 <!ENTITY app_prepare_request '<seealso marker="diameter_app#Mod:prepare_request-3">prepare_request/3</seealso>'>
 
 <!ENTITY app_capabilities '<seealso marker="diameter_app#capabilities">diameter_app:capabilities()</seealso>'>
-<!ENTITY app_message '<seealso marker="diameter_app#message">diameter_app:message()</seealso>'>
-<!ENTITY app_packet '<seealso marker="diameter_app#packet">diameter_app:packet()</seealso>'>
 <!ENTITY app_peer '<seealso marker="diameter_app#peer">diameter_app:peer()</seealso>'>
 <!ENTITY app_peer_ref '<seealso marker="diameter_app#peer_ref">diameter_app:peer_ref()</seealso>'>
 <!ENTITY app_state '<seealso marker="diameter_app#state">diameter_app:state()</seealso>'>
 
+<!-- diameter_codec -->
+
+<!ENTITY codec_encode '<seealso marker="diameter_codec#encode-2">diameter_codec:encode/2</seealso>'>
+<!ENTITY codec_decode '<seealso marker="diameter_codec#decode-2">diameter_codec:decode/2</seealso>'>
+
+<!ENTITY codec_avp '<seealso marker="diameter_codec#avp">diameter_codec:avp()</seealso>'>
+<!ENTITY codec_header '<seealso marker="diameter_codec#header">diameter_codec:header()</seealso>'>
+<!ENTITY codec_dictionary '<seealso marker="diameter_codec#dictionary">diameter_codec:dictionary()</seealso>'>
+<!ENTITY codec_message '<seealso marker="diameter_codec#message">diameter_codec:message()</seealso>'>
+<!ENTITY codec_packet '<seealso marker="diameter_codec#packet">diameter_codec:packet()</seealso>'>
+
 <!-- diameter_dict -->
 
 <!ENTITY dict_data_types '<seealso marker="diameter_dict#DATA_TYPES">diameter_dict(4)</seealso>'>
@@ -95,6 +106,14 @@ significant.
 <!ENTITY dict_UTF8String '<seealso marker="diameter_dict#DATA_TYPES">UTF8String()</seealso>'>
 <!ENTITY dict_Unsigned32 '<seealso marker="diameter_dict#DATA_TYPES">Unsigned32()</seealso>'>
 
+<!ENTITY dict_name '<seealso marker="diameter_dict#name">@name</seealso>'>
+<!ENTITY dict_prefix '<seealso marker="diameter_dict#prefix">@prefix</seealso>'>
+<!ENTITY dict_inherits '<seealso marker="diameter_dict#inherits">@inherits</seealso>'>
+
+<!-- diameter_make -->
+
+<!ENTITY make_codec '<seealso marker="diameter_make#codec-2">diameter_make:codec/2</seealso>'>
+
 <!-- diameter_transport -->
 
 <!ENTITY transport_start
@@ -105,8 +124,9 @@ significant.
 <!ENTITY man_compile '<seealso marker="diameterc">diameterc(1)</seealso>'>
 <!ENTITY man_main '<seealso marker="diameter">diameter(3)</seealso>'>
 <!ENTITY man_app '<seealso marker="diameter_app">diameter_app(3)</seealso>'>
+<!ENTITY man_codec '<seealso marker="diameter_codec">diameter_codec(3)</seealso>'>
 <!ENTITY man_dict '<seealso marker="diameter_dict">diameter_dict(4)</seealso>'>
-<!ENTITY man_transport
-   '<seealso marker="diameter_transport">diameter_transport(3)</seealso>'>
+<!ENTITY man_make '<seealso marker="diameter_make">diameter_make(3)</seealso>'>
+<!ENTITY man_transport '<seealso marker="diameter_transport">diameter_transport(3)</seealso>'>
 <!ENTITY man_sctp '<seealso marker="diameter_sctp">diameter_sctp(3)</seealso>'>
 <!ENTITY man_tcp  '<seealso marker="diameter_tcp">diameter_tcp(3)</seealso>'>