From 0af20bdcfb54a648d4b0c907565171a46afd1457 Mon Sep 17 00:00:00 2001
From: Ingela Anderton Andin
Date: Thu, 30 Apr 2015 09:47:45 +0200
Subject: ssl: Align with application naming rules
ssl SSL
crypto Crypto
stdlib STDLIB
kernel Kernel
public_key Public Key
---
lib/ssl/doc/src/ssl.xml | 29 ++++++++++++-----------
lib/ssl/doc/src/ssl_app.xml | 16 ++++++-------
lib/ssl/doc/src/ssl_distribution.xml | 38 +++++++++++++++----------------
lib/ssl/doc/src/ssl_protocol.xml | 10 ++++----
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.
- Ephemeral Diffie-Hellman cipher suites are supported,
but not Diffie Hellman Certificates cipher suites.
- - Elliptic Curve cipher suites are supported if the crypto
+
- Elliptic Curve cipher suites are supported if the Crypto
application supports it and named curves are used.
- Export cipher suites are not supported as the
@@ -63,7 +63,7 @@
DATA TYPES
-
The following data types are used in the functions for ssl:
+ The following data types are used in the functions for SSL:
@@ -81,7 +81,7 @@
For valid options, see the
inet(3) and
gen_tcp(3) manual pages
- in kernel.
+ in Kernel.
= {verify, verify_type()}
@@ -261,7 +261,7 @@ atom()}} |
The verification fun is called during the X509-path
- validation when an error or an extension unknown to the ssl
+ 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
TLS protocol versions supported by started clients and servers.
This option overrides the application environment option
protocol_version. If the environment option is not set, it defaults
- to all versions, except SSL-3.0, supported by the ssl application.
+ to all versions, except SSL-3.0, supported by the SSL application.
See also ssl(6).
{hibernate_after, integer()|undefined}
@@ -999,21 +999,21 @@ fun(srp, Username :: string(), UserState :: term()) ->
start() ->
start(Type) -> ok | {error, Reason}
- Starts the sslapplication.
+ Starts the SSL application.
Type = permanent | transient | temporary
- Starts the ssl application. Default type
+
Starts the SSL application. Default type
is temporary.
stop() -> ok
- Stops the ssl application.
+ Stops the SSL application.
- Stops the ssl application.
+ Stops the SSL application.
@@ -1055,16 +1055,16 @@ fun(srp, Username :: string(), UserState :: term()) ->
versions() -> [versions_info()]
Returns version information relevant for the
- ssl application.
+ SSL application.
versions_info() = {app_vsn, string()} | {supported | available, [protocol()]
- Returns version information relevant for the ssl
+
Returns version information relevant for the SSL
application.
app_vsn
- - The application version of the ssl application.
+ - The application version of the SSL application.
supported
- TLS/SSL versions supported by default.
@@ -1077,8 +1077,8 @@ fun(srp, Username :: string(), UserState :: term()) ->
.
available
- - All TLS/SSL versions supported by the ssl application.
- TLS 1.2 requires sufficient support from the crypto
+
- All TLS/SSL versions supported by the SSL application.
+ TLS 1.2 requires sufficient support from the Crypto
application.
@@ -1094,4 +1094,3 @@ fun(srp, Username :: string(), UserState :: term()) ->
-
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 @@
DEPENDENCIES
- The ssl application uses the public_key and
- crypto application to handle public keys and encryption, hence
- these applications must be loaded for the ssl application to work.
+
The SSL application uses the public_key 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
- application:start/[1,2] before the ssl application is
+ application:start/[1,2] before the SSL application is
started.
CONFIGURATION
The application environment configuration parameters in this section
- are defined for the ssl application. For more information
+ are defined for the SSL application. For more information
about configuration parameters, see the
application(3)
- manual page in kernel.
+ manual page in Kernel.
The environment parameters can be set on the command line,
for example:
@@ -60,7 +60,7 @@
ssl:protocol() ]]>.
Protocol supported by started clients and
servers. If this option is not set, it defaults to all
- protocols currently supported by the ssl application.
+ protocols currently supported by the SSL application.
This option can be overridden by the version option
to ssl:connect/[2,3] and ssl:listen/2.
@@ -91,7 +91,7 @@
ERROR LOGGER AND EVENT HANDLERS
- The ssl applications uses the default OTP error logger to log unexpected errors and TLS alerts. The logging of TLS alerts may be turned off with the log_alert option.
+ The SSL application uses the default OTP error logger to log unexpected errors and TLS alerts. The logging of TLS alerts may be turned off with the log_alert option.
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 inet_tcp_dist
- in the kernel application. When starting an
+ in the Kernel application. When starting an
Erlang node distributed, net_kernel uses this module to
set up listen ports and connections.
- In the ssl application, an exra distribution
+
In the SSL application, an exra distribution
module, inet_tls_dist, 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 @@
- Step 1: Build boot scripts including the
- ssl application.
+ SSL application.
- Step 3: Specify the security options and other
@@ -74,8 +74,8 @@
see the sasl documentation. This is only an example of
what can be done.
-
The simplest boot script possible includes only the kernel
- and stdlib applications. Such a script is located in the
+
The simplest boot script possible includes only the Kernel
+ and STDLIB applications. Such a script is located in the
bin directory of the Erlang distribution. The source for the
script is found under the Erlang installation top directory under
/start_clean.rel]]>.
@@ -84,12 +84,12 @@
Copy that script to another location (and preferably another
name).
- Add the applications crypto, public_key, and
- ssl with their current version numbers after the
- stdlibapplication.
+ Add the applications Crypto, Public Key, and
+ SSL with their current version numbers after the
+ STDLIB application.
- The following shows an example .rel file with ssl
+
The following shows an example .rel file with SSL
added:
{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> ]]>
- The whereis function-call verifies that the ssl
+
The whereis function-call verifies that the SSL
application is started.
As an alternative to building a bootscript, you can explicitly
- add the path to the ssl ebin directory on the command
+ add the path to the SSL ebin directory on the command
line. This is done with command-line option -pa. This
- 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.
+ 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 -pa method is only recommended for testing purposes.
- The clone of the ssl application must
+ 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 ssl application.
+ impossible to soft upgrade the SSL application.
Specifying Distribution Module for net_kernel
- The distribution module for ssl is named inet_tls_dist
+
The distribution module for SSL is named inet_tls_dist
and is specified on the command line with option -proto_dist.
The argument to -proto_dist is to be the module
name without suffix _dist. So, this distribution
@@ -172,7 +172,7 @@ Eshell V5.0 (abort with ^G)
(ssl_test@myhost)1>
However, a node started in this way refuses to talk
- to other nodes, as no ssl parameters are supplied
+ to other nodes, as no SSL parameters are supplied
(see the next 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 @@
ssl_protocol.xml
- The Erlang ssl application implements the SSL/TLS protocol
+
The Erlang SSL application implements the SSL/TLS protocol
for the currently supported versions, see the
ssl(3) manual page.
- By default ssl is run over the TCP/IP protocol even
+
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
- gen_tcp module in kernel.
+ gen_tcp module in Kernel.
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 ssl 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.
@@ -143,7 +143,7 @@
connections. Sessions are used to avoid the expensive negotiation
of new security parameters for each connection."
- Session data is by default kept by the ssl application in a
+
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
init function, hence putting the same requirements on it
as a normal process init function. This function is
- called twice when starting the ssl application, once with
- the role client and once with the role server, as the ssl
+ 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.
--
cgit v1.2.3