diff options
| -rw-r--r-- | lib/ssl/doc/src/ssl.xml | 29 | ||||
| -rw-r--r-- | lib/ssl/doc/src/ssl_app.xml | 16 | ||||
| -rw-r--r-- | lib/ssl/doc/src/ssl_distribution.xml | 38 | ||||
| -rw-r--r-- | lib/ssl/doc/src/ssl_protocol.xml | 10 | ||||
| -rw-r--r-- | lib/ssl/doc/src/ssl_session_cache_api.xml | 4 |
5 files changed, 48 insertions, 49 deletions
diff --git a/lib/ssl/doc/src/ssl.xml b/lib/ssl/doc/src/ssl.xml index c5fe8b69a4..14873848d1 100644 --- a/lib/ssl/doc/src/ssl.xml +++ b/lib/ssl/doc/src/ssl.xml @@ -45,7 +45,7 @@ but can be configured.</item> <item>Ephemeral Diffie-Hellman cipher suites are supported, but not Diffie Hellman Certificates cipher suites.</item> - <item>Elliptic Curve cipher suites are supported if the <c>crypto</c> + <item>Elliptic Curve cipher suites are supported if the Crypto application supports it and named curves are used. </item> <item>Export cipher suites are not supported as the @@ -63,7 +63,7 @@ <section> <title>DATA TYPES</title> - <p>The following data types are used in the functions for <c>ssl</c>:</p> + <p>The following data types are used in the functions for SSL:</p> <taglist> @@ -81,7 +81,7 @@ <p>For valid options, see the <seealso marker="kernel:inet">inet(3)</seealso> and <seealso marker="kernel:gen_tcp">gen_tcp(3)</seealso> manual pages - in <c>kernel</c>.</p></item> + in Kernel.</p></item> <tag><c>ssloption()</c></tag> <item><p><c>= {verify, verify_type()}</c></p> @@ -261,7 +261,7 @@ atom()}} | </code> <p>The verification fun is called during the X509-path - validation when an error or an extension unknown to the <c>ssl</c> + validation when an error or an extension unknown to the SSL application is encountered. It is also called when a certificate is considered valid by the path validation to allow access to each certificate in the path to the user @@ -382,7 +382,7 @@ marker="public_key:public_key#pkix_path_validation-3">public_key:pkix_path_valid <item><p>TLS protocol versions supported by started clients and servers. This option overrides the application environment option <c>protocol_version</c>. If the environment option is not set, it defaults - to all versions, except SSL-3.0, supported by the <c>ssl</c> application. + to all versions, except SSL-3.0, supported by the SSL application. See also <seealso marker="ssl:ssl_app">ssl(6).</seealso></p></item> <tag><c>{hibernate_after, integer()|undefined}</c></tag> @@ -999,21 +999,21 @@ fun(srp, Username :: string(), UserState :: term()) -> <func> <name>start() -> </name> <name>start(Type) -> ok | {error, Reason}</name> - <fsummary>Starts the <c>ssl</c>application.</fsummary> + <fsummary>Starts the SSL application.</fsummary> <type> <v>Type = permanent | transient | temporary</v> </type> <desc> - <p>Starts the <c>ssl</c> application. Default type + <p>Starts the SSL application. Default type is <c>temporary</c>.</p> </desc> </func> <func> <name>stop() -> ok </name> - <fsummary>Stops the <c>ssl</c> application.</fsummary> + <fsummary>Stops the SSL application.</fsummary> <desc> - <p>Stops the <c>ssl</c> application.</p> + <p>Stops the SSL application.</p> </desc> </func> @@ -1055,16 +1055,16 @@ fun(srp, Username :: string(), UserState :: term()) -> <func> <name>versions() -> [versions_info()]</name> <fsummary>Returns version information relevant for the - <c>ssl</c> application.</fsummary> + SSL application.</fsummary> <type> <v>versions_info() = {app_vsn, string()} | {supported | available, [protocol()] </v> </type> <desc> - <p>Returns version information relevant for the <c>ssl</c> + <p>Returns version information relevant for the SSL application.</p> <taglist> <tag><c>app_vsn</c></tag> - <item>The application version of the <c>ssl</c> application.</item> + <item>The application version of the SSL application.</item> <tag><c>supported</c></tag> <item>TLS/SSL versions supported by default. @@ -1077,8 +1077,8 @@ fun(srp, Username :: string(), UserState :: term()) -> </seealso>.</item> <tag><c>available</c></tag> - <item>All TLS/SSL versions supported by the <c>ssl</c> application. - TLS 1.2 requires sufficient support from the <c>crypto</c> + <item>All TLS/SSL versions supported by the SSL application. + TLS 1.2 requires sufficient support from the Crypto application.</item> </taglist> </desc> @@ -1094,4 +1094,3 @@ fun(srp, Username :: string(), UserState :: term()) -> </section> </erlref> - diff --git a/lib/ssl/doc/src/ssl_app.xml b/lib/ssl/doc/src/ssl_app.xml index 43c69ba377..f17f5cb9fe 100644 --- a/lib/ssl/doc/src/ssl_app.xml +++ b/lib/ssl/doc/src/ssl_app.xml @@ -35,21 +35,21 @@ <description></description> <section> <title>DEPENDENCIES</title> - <p>The <c>ssl</c> application uses the <c>public_key</c> and - <c>crypto</c> application to handle public keys and encryption, hence - these applications must be loaded for the <c>ssl</c> application to work. + <p>The SSL application uses the <c>public_key</c> and + Crypto application to handle public keys and encryption, hence + these applications must be loaded for the SSL application to work. In an embedded environment this means they must be started with - <c>application:start/[1,2]</c> before the <c>ssl</c> application is + <c>application:start/[1,2]</c> before the SSL application is started.</p> </section> <section> <title>CONFIGURATION</title> <p>The application environment configuration parameters in this section - are defined for the <c>ssl</c> application. For more information + are defined for the SSL application. For more information about configuration parameters, see the <seealso marker="kernel:application">application(3)</seealso> - manual page in <c>kernel</c>.</p> + manual page in Kernel.</p> <p>The environment parameters can be set on the command line, for example:</p> @@ -60,7 +60,7 @@ <tag><c><![CDATA[protocol_version = <seealso marker="kernel:error_logger">ssl:protocol()</seealso> <optional>]]></c>.</tag> <item><p>Protocol supported by started clients and servers. If this option is not set, it defaults to all - protocols currently supported by the <c>ssl</c> application. + protocols currently supported by the SSL application. This option can be overridden by the version option to <c>ssl:connect/[2,3]</c> and <c>ssl:listen/2</c>.</p></item> @@ -91,7 +91,7 @@ <section> <title>ERROR LOGGER AND EVENT HANDLERS</title> - <p>The <c>ssl</c> applications uses the default <seealso marker="kernel:error_logger">OTP error logger</seealso> to log unexpected errors and TLS alerts. The logging of TLS alerts may be turned off with the <c>log_alert</c> option. </p> + <p>The SSL application uses the default <seealso marker="kernel:error_logger">OTP error logger</seealso> to log unexpected errors and TLS alerts. The logging of TLS alerts may be turned off with the <c>log_alert</c> option. </p> </section> <section> diff --git a/lib/ssl/doc/src/ssl_distribution.xml b/lib/ssl/doc/src/ssl_distribution.xml index c9f7b1b27f..effb304938 100644 --- a/lib/ssl/doc/src/ssl_distribution.xml +++ b/lib/ssl/doc/src/ssl_distribution.xml @@ -38,11 +38,11 @@ connection-based protocol as bearer. However, a module that implements the protocol-specific parts of the connection setup is needed. The default distribution module is <c>inet_tcp_dist</c> - in the <c>kernel</c> application. When starting an + in the Kernel application. When starting an Erlang node distributed, <c>net_kernel</c> uses this module to set up listen ports and connections.</p> - <p>In the <c>ssl</c> application, an exra distribution + <p>In the SSL application, an exra distribution module, <c>inet_tls_dist</c>, can be used as an alternative. All distribution connections will use SSL and all participating Erlang nodes in a distributed system must use @@ -57,7 +57,7 @@ <list type="bulleted"> <item><em>Step 1:</em> Build boot scripts including the - <c>ssl</c> application.</item> + SSL application.</item> <item><em>Step 2:</em> Specify the distribution module for <c>net_kernel</c>.</item> <item><em>Step 3:</em> Specify the security options and other @@ -74,8 +74,8 @@ see the <c>sasl</c> documentation. This is only an example of what can be done.</p> - <p>The simplest boot script possible includes only the <c>kernel</c> - and <c>stdlib</c> applications. Such a script is located in the + <p>The simplest boot script possible includes only the Kernel + and STDLIB applications. Such a script is located in the <c>bin</c> directory of the Erlang distribution. The source for the script is found under the Erlang installation top directory under <c><![CDATA[releases/<OTP version>/start_clean.rel]]></c>.</p> @@ -84,12 +84,12 @@ <list type="bulleted"> <item><p>Copy that script to another location (and preferably another name).</p></item> - <item><p>Add the applications <c>crypto</c>, <c>public_key</c>, and - <c>ssl</c> with their current version numbers after the - <c>stdlib</c>application.</p></item> + <item><p>Add the applications Crypto, Public Key, and + SSL with their current version numbers after the + STDLIB application.</p></item> </list> - <p>The following shows an example <c>.rel</c> file with <c>ssl</c> + <p>The following shows an example <c>.rel</c> file with SSL added:</p> <code type="none"> {release, {"OTP APN 181 01","R15A"}, {erts, "5.9"}, @@ -132,27 +132,27 @@ Eshell V5.0 (abort with ^G) 1> whereis(ssl_manager). <0.41.0> ]]></code> - <p>The <c>whereis</c> function-call verifies that the <c>ssl</c> + <p>The <c>whereis</c> function-call verifies that the SSL application is started.</p> <p>As an alternative to building a bootscript, you can explicitly - add the path to the <c>ssl</c> <c>ebin</c> directory on the command + add the path to the SSL <c>ebin</c> directory on the command line. This is done with command-line option <c>-pa</c>. This - works as the <c>ssl</c> application does not need to be started for the - distribution to come up, as a clone of the <c>ssl</c> application is - hooked into the <c>kernel</c> application. So, as long as the - <c>ssl</c> application code can be reached, the distribution starts. + works as the SSL application does not need to be started for the + distribution to come up, as a clone of the SSL application is + hooked into the Kernel application. So, as long as the + SSL application code can be reached, the distribution starts. The <c>-pa</c> method is only recommended for testing purposes.</p> - <note><p>The clone of the <c>ssl</c> application must + <note><p>The clone of the SSL application must enable the use of the SSL code in such an early bootstage as needed to set up the distribution. However, this makes it - impossible to soft upgrade the <c>ssl</c> application.</p></note> + impossible to soft upgrade the SSL application.</p></note> </section> <section> <title>Specifying Distribution Module for net_kernel</title> - <p>The distribution module for <c>ssl</c> is named <c>inet_tls_dist</c> + <p>The distribution module for SSL is named <c>inet_tls_dist</c> and is specified on the command line with option <c>-proto_dist</c>. The argument to <c>-proto_dist</c> is to be the module name without suffix <c>_dist</c>. So, this distribution @@ -172,7 +172,7 @@ Eshell V5.0 (abort with ^G) (ssl_test@myhost)1> </code> <p>However, a node started in this way refuses to talk - to other nodes, as no <c>ssl</c> parameters are supplied + to other nodes, as no SSL parameters are supplied (see the next section).</p> </section> diff --git a/lib/ssl/doc/src/ssl_protocol.xml b/lib/ssl/doc/src/ssl_protocol.xml index 20f53c98e1..cc49515066 100644 --- a/lib/ssl/doc/src/ssl_protocol.xml +++ b/lib/ssl/doc/src/ssl_protocol.xml @@ -32,19 +32,19 @@ <file>ssl_protocol.xml</file> </header> - <p>The Erlang <c>ssl</c> application implements the SSL/TLS protocol + <p>The Erlang SSL application implements the SSL/TLS protocol for the currently supported versions, see the <seealso marker="ssl">ssl(3)</seealso> manual page. </p> - <p>By default <c>ssl</c> is run over the TCP/IP protocol even + <p>By default SSL/TLS is run over the TCP/IP protocol even though you can plug in any other reliable transport protocol with the same Application Programming Interface (API) as the - <c>gen_tcp</c> module in <c>kernel</c>.</p> + <c>gen_tcp</c> module in Kernel.</p> <p>If a client and a server wants to use an upgrade mechanism, such as defined by RFC 2817, to upgrade a regular TCP/IP connection to an SSL - connection, this is supported by the Erlang <c>ssl</c> API. This can be + connection, this is supported by the Erlang SSL application API. This can be useful for, for example, supporting HTTP and HTTPS on the same port and implementing virtual hosting. </p> @@ -143,7 +143,7 @@ connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection."</p> - <p>Session data is by default kept by the <c>ssl</c> application in a + <p>Session data is by default kept by the SSL application in a memory storage, hence session data is lost at application restart or takeover. Users can define their own callback module to handle session data storage if persistent data storage is diff --git a/lib/ssl/doc/src/ssl_session_cache_api.xml b/lib/ssl/doc/src/ssl_session_cache_api.xml index 9cd16c5f58..c89d3874a1 100644 --- a/lib/ssl/doc/src/ssl_session_cache_api.xml +++ b/lib/ssl/doc/src/ssl_session_cache_api.xml @@ -108,8 +108,8 @@ API functions. Is called by the cache handling processes <c>init</c> function, hence putting the same requirements on it as a normal process <c>init</c> function. This function is - called twice when starting the <c>ssl</c> application, once with - the role client and once with the role server, as the <c>ssl</c> + called twice when starting the SSL application, once with + the role client and once with the role server, as the SSL application must be prepared to take on both roles. </p> </desc> |