Merge branch 'maint'

23 files changed, 2587 insertions, 2838 deletions

diff --git a/lib/inets/doc/src/Makefile b/lib/inets/doc/src/Makefile
index a0a3472c4a..cb71fbeb9c 100644
--- a/lib/inets/doc/src/Makefile
+++ b/lib/inets/doc/src/Makefile
@@ -52,7 +52,6 @@ XML_REF3_FILES = \
 	http_uri.xml\
 	httpc.xml\
 	httpd.xml \
-	httpd_conf.xml \
 	httpd_custom_api.xml \
 	httpd_socket.xml \
 	httpd_util.xml \
diff --git a/lib/inets/doc/src/ftp.xml b/lib/inets/doc/src/ftp.xml
index f3d4a5c45d..f64bc0e18b 100644
--- a/lib/inets/doc/src/ftp.xml
+++ b/lib/inets/doc/src/ftp.xml
@@ -30,95 +30,94 @@
     <file>ftp.xml</file>
   </header>
   <module>ftp</module>
-  <modulesummary>A File Transfer Protocol client</modulesummary>
+  <modulesummary>A File Transfer Protocol client.</modulesummary>
 
   <description>
 
-    <p>The <c>ftp</c> module implements a client for file transfer
-      according to a subset of the File Transfer Protocol (see <term
-      id="RFC"></term>959). </p>
+    <p>This module implements a client for file transfer
+      according to a subset of the File Transfer Protocol (FTP), see
+    <url href="http://www.ietf.org/rfc/rfc959.txt">RFC 959</url>.</p>
 
-    <p>Starting from inets version 4.4.1 the ftp
-      client will always try to use passive ftp mode and only resort
-      to active ftp mode if this fails. There is a start option 
-      <seealso marker="#mode">mode</seealso> where this default behavior 
-      may be changed. </p>
+    <p>As from <c>Inets</c> 4.4.1, the FTP
+      client always tries to use passive FTP mode and only resort
+      to active FTP mode if this fails. This default behavior can be 
+      changed by start option <seealso marker="#mode">mode</seealso>.</p>
 
     <marker id="two_start"></marker>
 
-    <p>There are two ways to start an ftp client. One is using the 
-      <seealso marker="#service_start">Inets service framework</seealso>
-      and the other is to start it directy as a standalone process 
-      using the <seealso marker="#open">open</seealso> function. </p>
+    <p>An FTP client can be started in two ways. One is using the 
+      <seealso marker="#service_start">Inets service framework</seealso>,
+      the other is to start it directly as a standalone process 
+      using function <seealso marker="#open">open</seealso>.</p>
 
-    <p>For a simple example of an ftp session see 
-      <seealso marker="ftp_client">Inets User's Guide.</seealso></p>
+    <p>For a simple example of an FTP session, see 
+      <seealso marker="ftp_client">Inets User's Guide</seealso>.</p>
 
     <p>In addition to the ordinary functions for receiving and sending
-      files (see <c>recv/2</c>, <c>recv/3</c>, <c>send/2</c> and
+      files (see <c>recv/2</c>, <c>recv/3</c>, <c>send/2</c>, and
       <c>send/3</c>) there are functions for receiving remote files as
-      binaries (see <c>recv_bin/2</c>) and for sending binaries to to be
+      binaries (see <c>recv_bin/2</c>) and for sending binaries to be
       stored as remote files (see <c>send_bin/3</c>).</p>
 
-    <p>There is also a set of functions for sending and receiving
-      contiguous parts of a file to be stored in a remote file (for send
-      see <c>send_chunk_start/2</c>, <c>send_chunk/2</c> and
-      <c>send_chunk_end/1</c> and for receive see
+    <p>A set of functions is provvided for sending and receiving
+      contiguous parts of a file to be stored in a remote file. For send,
+      see <c>send_chunk_start/2</c>, <c>send_chunk/2</c>, and
+      <c>send_chunk_end/1</c>. For receive, see
       <c>recv_chunk_start/2</c> and <c>recv_chunk/</c>).</p>
 
-    <p>The particular return values of the functions below depend very
+    <p>The return values of the following functions depend
       much on the implementation of the FTP server at the remote
-      host. In particular the results from <c>ls</c> and <c>nlist</c>
+      host. In particular, the results from <c>ls</c> and <c>nlist</c>
       varies. Often real errors are not reported as errors by <c>ls</c>,
-      even if for instance a file or directory does not
+      even if, for example, a file or directory does not
       exist. <c>nlist</c> is usually more strict, but some
       implementations have the peculiar behaviour of responding with an
-      error, if the request is a listing of the contents of directory
-      which exists but is empty.</p>
+      error if the request is a listing of the contents of a directory
+      that exists but is empty.</p>
 
     <marker id="service_start"></marker>
   </description>
 
   <section>
-    <title>FTP CLIENT SERVICE START/STOP </title>
+    <title>FTP CLIENT SERVICE START/STOP</title>
     
     <p>The FTP client can be started and stopped dynamically in runtime by
-      calling the Inets application API 
+      calling the <c>Inets</c> application API 
       <c>inets:start(ftpc, ServiceConfig)</c>,
       or <c>inets:start(ftpc, ServiceConfig, How)</c>, and
       <c>inets:stop(ftpc, Pid)</c>. 
-      See <seealso marker="inets">inets(3)</seealso> for more info. </p>
-    <p>Below follows a description of
-      the available configuration options.</p>
+      For details, see <seealso marker="inets">inets(3)</seealso>.</p>
+
+    <p>The available configuration options are as follows:</p>
     
     <taglist>
       <tag>{host, Host}</tag>
       <item>
         <marker id="host"></marker>
-	<p>Host = <c>string() | ip_address()</c> </p>
+	<p>Host = <c>string() | ip_address()</c></p>
       </item>
 
       <tag>{port, Port}</tag>
       <item>
         <marker id="port"></marker>
-	<p>Port = <c>integer() > 0</c> </p>
-	<p>Default is 21.</p>
+	<p>Port = <c>integer() > 0</c></p>
+	<p>Default is <c>21</c>.</p>
       </item>
 
       <tag>{mode, Mode}</tag>
       <item>
         <marker id="mode"></marker>
-	<p>Mode = <c>active | passive</c> </p>
-	<p>Default is <c>passive</c>. </p> 
+	<p>Mode = <c>active | passive</c></p>
+	<p>Default is <c>passive</c>.</p> 
       </item>
 
       <tag>{verbose, Verbose}</tag>
       <item>
         <marker id="verbose"></marker>
 	<p>Verbose = <c>boolean()</c> </p>
-	<p>This determines if the FTP communication should be
-	  verbose or not. </p>
-	<p>Default is <c>false</c>. </p>
+	<p>Determines if the FTP communication is to be
+	  verbose or not.</p>
+	<p>Default is <c>false</c>.</p>
       </item>
 
       <tag>{debug, Debug}</tag>
@@ -126,93 +125,90 @@
         <marker id="debug"></marker>
 	<p>Debug = <c>trace | debug | disable</c> </p>
 	<p>Debugging using the dbg toolkit. </p>
-	<p>Default is <c>disable</c>. </p>
+	<p>Default is <c>disable</c>.</p>
       </item>
 
       <tag>{ipfamily, IpFamily}</tag>
       <item>
         <marker id="ipfamily"></marker>
 	<p>IpFamily = <c>inet | inet6 | inet6fb4</c> </p>
-	<p>With <c>inet6fb4</c> the client behaves as before 
-	  (it tries to use IPv6 and only if that does not work, it 
-          uses IPv4). </p>
-	<p>Default is <c>inet</c> (IPv4). </p>
+	<p>With <c>inet6fb4</c> the client behaves as before, that is, 
+	  tries to use IPv6, and only if that does not work it
+          uses IPv4).</p>
+	<p>Default is <c>inet</c> (IPv4).</p>
       </item>
 
       <tag>{timeout, Timeout}</tag>
       <item>
         <marker id="timeout"></marker>
-	<p>Timeout = <c>non_neg_integer()</c> </p>
-	<p>Connection timeout. </p>
-	<p>Default is 60000 (milliseconds). </p>
+	<p>Timeout = <c>non_neg_integer()</c></p>
+	<p>Connection time-out.</p>
+	<p>Default is <c>60000</c> (milliseconds).</p>
       </item>
 
       <tag>{dtimeout, DTimeout}</tag>
       <item>
         <marker id="dtimeout"></marker>
 	<p>DTimeout = <c>non_neg_integer() | infinity</c> </p>
-	<p>Data Connect timeout. 
-	The time the client will wait for the server to connect to the 
-	data socket. </p>
-	<p>Default is infinity. </p>
+	<p>Data connect time-out. 
+	The time the client waits for the server to connect to the 
+	data socket.</p>
+	<p>Default is <c>infinity</c>. </p>
       </item>
 
       <tag>{progress, Progress}</tag>
       <item>
         <marker id="progress"></marker>
 	<p>Progress = <c>ignore | {CBModule, CBFunction, InitProgress}</c></p>
-	<p>CBModule = <c>atom()</c>, CBFunction = <c>atom()</c> </p>
-	<p>InitProgress = <c>term()</c> </p>
-	<p>Default is <c>ignore</c>. </p>
+	<p><c>CBModule = atom()</c>, <c>CBFunction = atom()</c></p>
+	<p><c>InitProgress = term()</c></p>
+	<p>Default is <c>ignore</c>.</p>
       </item>  
 
     </taglist>
   
-    <p>The progress option is intended to be used by applications that
-      want to create some type of progress report such as a progress bar in
-      a GUI.  The default value for the progress option is ignore
-      e.i. the option is not used.  When the progress option is
-      specified the following will happen when ftp:send/[3,4] or
-      ftp:recv/[3,4] are called.</p>
+    <p>Option <c>progress</c> is intended to be used by applications that
+      want to create some type of progress report, such as a progress bar in
+      a GUI. Default for the progress option is <c>ignore</c>,
+      that is, the option is not used. When the progress option is
+      specified, the following happens when <c>ftp:send/[3,4]</c> or
+      <c>ftp:recv/[3,4]</c> are called:</p>
     
     <list type="bulleted">
       <item>
-	<p>Before a file is transfered the following call will
-	  be made to indicate the start of the file transfer and how big
+	<p>Before a file is transferred, the following call is
+	  made to indicate the start of the file transfer and how large
 	  the file is. The return value of the callback function
-	  should be a new value for the UserProgressTerm that will
-	  bu used as input next time the callback function is
+	  is to be a new value for the <c>UserProgressTerm</c> that will
+	  be used as input the next time the callback function is
 	  called.</p>
-	<br></br>
 	<p><c>
 	  CBModule:CBFunction(InitProgress, File, {file_size, FileSize})
 	</c></p>
-	<br></br>
       </item>
       
       <item>
-	<p>Every time a chunk of bytes is transfered the
-	  following call will be made:</p>
-	<br></br>
+	<p>Every time a chunk of bytes is transferred the
+	  following call is made:</p>
 	<p><c>
-	    CBModule:CBFunction(UserProgressTerm, File, {transfer_size, TransferSize})             </c></p>
-	<br></br>
+	    CBModule:CBFunction(UserProgressTerm, File, {transfer_size, TransferSize})
+        </c></p>
       </item>
 
       <item>
-	<p>At the end of the file the following call will be
-	  made to indicate the end of the transfer.</p>
-	<br></br>
+	<p>At the end of the file the following call is
+	  made to indicate the end of the transfer:</p>
 	<p><c>
-	    CBModule:CBFunction(UserProgressTerm, File, {transfer_size, 0})             </c></p>
-	<br></br>
+	    CBModule:CBFunction(UserProgressTerm, File, {transfer_size, 0})      
+	</c></p>
       </item>
     </list>
     
-    <p>The callback function should be defined as </p>
+    <p>The callback function is to be defined as follows:</p>
 
     <p><c>
-	CBModule:CBFunction(UserProgressTerm, File, Size) -> UserProgressTerm        </c></p>
+	CBModule:CBFunction(UserProgressTerm, File, Size) -> UserProgressTerm
+    </c></p>
     
     <p><c>
 	CBModule = CBFunction = atom()
@@ -227,50 +223,51 @@
       </c></p>
 
     <p><c>
-	Size = {transfer_size, integer()} | {file_size, integer()} | {file_size, unknown}        </c></p>
+	Size = {transfer_size, integer()} | {file_size, integer()} | {file_size, unknown}
+    </c></p>
     
-    <p>Alas for remote files it is not possible for ftp to determine the
+    <p>For remote files, <c>ftp</c> cannot determine the
       file size in a platform independent way. In this case the size
-      will be <c>unknown</c> and it is left to the application to find
-      out the size. </p>
+      becomes <c>unknown</c> and it is left to the application to
+      determine the size.</p>
     
     <note>
       <p>The callback is made by a middleman process, hence the
-	file transfer will not be affected by the code in the progress
-	callback function. If the callback should crash this will be
-	detected by the ftp connection process that will print an
-	info-report and then go one as if the progress option was set
-	to ignore. </p>
+	file transfer is not affected by the code in the progress
+	callback function. If the callback crashes, this is
+	detected by the FTP connection process, which then prints an
+	info-report and goes on as if the progress option was set
+	to <c>ignore</c>.</p>
     </note>
     
     <p>The file transfer type is set to the default of the FTP server
-      when the session is opened. This is usually ASCCI-mode.
+      when the session is opened. This is usually ASCCI mode.
     </p>
     
-    <p>The current local working directory (cf. <c>lpwd/1</c>) is set to
-      the value reported by <c>file:get_cwd/1</c>. the wanted
+    <p>The current local working directory (compare <c>lpwd/1</c>) is set 
+      to the value reported by <c>file:get_cwd/1</c>, the wanted
       local directory.
     </p>
     
     <p>The return value <c>Pid</c> is used as a reference to the
-      newly created ftp client in all other functions, and they should
-      be called by the process that created the connection. The ftp
+      newly created FTP client in all other functions, and they are to
+      be called by the process that created the connection. The FTP
       client process monitors the process that created it and
-      will terminate if that process terminates.</p>   
+      terminates if that process terminates.</p>   
   </section>
   
   <section>
-    <title>COMMON DATA TYPES </title>
-    <p>Here follows type definitions that are used by more than one
-      function in the FTP client API. </p>
-    <p><c> pid() - identifier of an ftp connection.</c></p>
-    <p><c> string() = list of ASCII characters.</c></p>
-    <p><c> shortage_reason() = etnospc | epnospc</c></p>
-    <p><c> restriction_reason() = epath | efnamena | elogin | enotbinary
-      - note not all restrictions may always relevant to all functions
-    </c></p>
-    <p><c>common_reason() = econn | eclosed | term() - some kind of
-      explanation of what went wrong.</c></p>
+    <title>DATA TYPES</title>
+    <p>The following type definitions are used by more than one
+      function in the FTP client API:</p>
+    <p><c>pid()</c> = identifier of an FTP connection</p>
+    <p><c>string()</c> = list of ASCII characters</p>
+    <p><c>shortage_reason()</c> = <c>etnospc | epnospc</c></p>
+    <p><c>restriction_reason()</c> = <c>epath | efnamena | elogin | enotbinary</c>
+      -  all restrictions are not always relevant to all functions
+    </p>
+    <p><c>common_reason()</c> = <c>econn | eclosed | term()</c> 
+      - some explanation of what went wrong</p>
 
     <marker id="account"></marker>
   </section>
@@ -278,15 +275,14 @@
   <funcs>
     <func>
       <name>account(Pid, Account) -> ok | {error, Reason}</name>
-      <fsummary>Specify which account to use.</fsummary>
+      <fsummary>Specifies which account to use.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Account = string()</v>
         <v>Reason = eacct | common_reason()</v>
       </type>
       <desc>
-        <p>If an account is needed for an operation set the account
-          with this operation.</p>
+        <p>Sets the account for an operation, if needed.</p>
 
        <marker id="append"></marker>
        <marker id="append2"></marker>
@@ -297,7 +293,8 @@
     <func>
       <name>append(Pid, LocalFile) -> </name>
       <name>append(Pid, LocalFile, RemoteFile) -> ok | {error, Reason}</name>
-      <fsummary>Transfer file to remote server, and append it to Remotefile.</fsummary>
+      <fsummary>Transfers a file to remote server, and appends it to 
+      <c>Remotefile</c>.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>LocalFile = RemoteFile = string()</v>
@@ -306,9 +303,9 @@
       <desc>
         <p>Transfers the file <c>LocalFile</c> to the remote server. If 
           <c>RemoteFile</c> is specified, the name of the remote file that the
-          file will be appended to is set to <c>RemoteFile</c>; otherwise 
-          the name is set to <c>LocalFile</c> If the file does not exists the
-          file will be created.</p>
+          file is appended to is set to <c>RemoteFile</c>, otherwise 
+          to <c>LocalFile</c>. If the file does not exists,
+          it is created.</p>
 
        <marker id="append_bin"></marker>
       </desc>
@@ -316,17 +313,17 @@
 
     <func>
       <name>append_bin(Pid, Bin, RemoteFile) -> ok | {error, Reason}</name>
-      <fsummary>Transfer a binary into a remote file.</fsummary>
+      <fsummary>Transfers a binary into a remote file.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Bin = binary()()</v>
         <v>RemoteFile = string()</v>
-        <v>Reason =  restriction_reason()| shortage_reason() | common_reason()</v>
+        <v>Reason = restriction_reason()| shortage_reason() | common_reason()</v>
       </type>
       <desc>
-        <p>Transfers the binary <c>Bin</c> to the remote server and append 
-          it to the file <c>RemoteFile</c>. If the file does not exists it 
-          will be created.</p>
+        <p>Transfers the binary <c>Bin</c> to the remote server and appends 
+          it to the file <c>RemoteFile</c>. If the file does not exist, it 
+          is created.</p>
 
        <marker id="append_chunk"></marker>
       </desc>
@@ -334,18 +331,18 @@
 
     <func>
       <name>append_chunk(Pid, Bin) -> ok | {error, Reason}</name>
-      <fsummary>append a chunk to the remote file.</fsummary>
+      <fsummary>Appends a chunk to the remote file.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Bin = binary()</v>
         <v>Reason = echunk | restriction_reason() | common_reason()</v>
       </type>
       <desc>
-        <p>Transfer the chunk <c>Bin</c> to the remote server, which 
-          append it into the file specified in the call to 
-          <c>append_chunk_start/2</c>. </p>
-        <p>Note that for some errors, e.g. file system full, it is 
-          necessary to to call <c>append_chunk_end</c> to get the 
+        <p>Transfers the chunk <c>Bin</c> to the remote server, which 
+          appends it to the file specified in the call to 
+          <c>append_chunk_start/2</c>.</p>
+        <p>For some errors, for example, file system full, it is 
+          necessary to call <c>append_chunk_end</c> to get the 
           proper reason.</p>
 
        <marker id="append_chunk_start"></marker>
@@ -354,16 +351,16 @@
 
     <func>
       <name>append_chunk_start(Pid, File) -> ok | {error, Reason}</name>
-      <fsummary>Start transfer of file chunks for appending to File.</fsummary>
+      <fsummary>Starts transfer of file chunks for appending to <c>File</c>.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>File = string()</v>
         <v>Reason = restriction_reason() | common_reason()</v>
       </type>
       <desc>
-        <p>Start the transfer of chunks for appending to the file 
-          <c>File</c> at the remote server. If the file does not exists 
-          it will be created.</p>
+        <p>Starts the transfer of chunks for appending to the file 
+          <c>File</c> at the remote server. If the file does not exist, 
+          it is created.</p>
 
        <marker id="append_chunk_end"></marker>
       </desc>
@@ -371,7 +368,7 @@
 
     <func>
       <name>append_chunk_end(Pid) -> ok | {error, Reason}</name>
-      <fsummary>Stop transfer of chunks for appending.</fsummary>
+      <fsummary>Stops transfer of chunks for appending.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Reason = echunk | restriction_reason() | shortage_reason() </v>
@@ -379,7 +376,7 @@
       <desc>
         <p>Stops transfer of chunks for appending to the remote server. 
           The file at the remote server, specified in the call to 
-          <c>append_chunk_start/2</c> is closed by the server.</p>
+          <c>append_chunk_start/2</c>, is closed by the server.</p>
 
        <marker id="cd"></marker>
       </desc>
@@ -387,7 +384,7 @@
 
     <func>
       <name>cd(Pid, Dir) -> ok | {error, Reason}</name>
-      <fsummary>Change remote working directory.</fsummary>
+      <fsummary>Changes remote working directory.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Dir = string()</v>
@@ -403,13 +400,13 @@
     
     <func>
       <name>close(Pid) -> ok</name>
-      <fsummary>End the ftp session.</fsummary>
+      <fsummary>Ends the FTP session.</fsummary>
       <type>
 	<v>Pid = pid()</v>
       </type>
       <desc>
-	<p>Ends an ftp session, created using the 
-          <seealso marker="#open">open</seealso> function. </p>
+	<p>Ends an FTP session, created using function
+          <seealso marker="#open">open</seealso>.</p>
 
        <marker id="delete"></marker>
       </desc>
@@ -417,7 +414,7 @@
 
     <func>
       <name>delete(Pid, File) -> ok | {error, Reason}</name>
-      <fsummary>Delete a file at the remote server..</fsummary>
+      <fsummary>Deletes a file at the remote server.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>File = string()</v>
@@ -432,7 +429,7 @@
 
     <func>
       <name>formaterror(Tag) -> string()</name>
-      <fsummary>Return error diagnostics.</fsummary>
+      <fsummary>Returns error diagnostics.</fsummary>
       <type>
         <v>Tag = {error, atom()} | atom()</v>
       </type>
@@ -446,14 +443,14 @@
 
     <func>
       <name>lcd(Pid, Dir) -> ok | {error, Reason}</name>
-      <fsummary>Change local working directory.</fsummary>
+      <fsummary>Changes local working directory.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Dir = string()</v>
         <v>Reason = restriction_reason()</v>
       </type>
       <desc>
-        <p>Changes the working directory to <c>Dir</c> for the local client. </p>
+        <p>Changes the working directory to <c>Dir</c> for the local client.</p>
 
        <marker id="lpwd"></marker>
       </desc>
@@ -461,7 +458,7 @@
 
     <func>
       <name>lpwd(Pid) -> {ok, Dir}</name>
-      <fsummary>Get local current working directory.</fsummary>
+      <fsummary>Gets local current working directory.</fsummary>
       <type>
         <v>Pid = pid()</v>
       </type>
@@ -485,13 +482,13 @@
         <v>Reason = restriction_reason() | common_reason()</v>
       </type>
       <desc>
-        <p>Returns a list of files in long format. </p>
-        <p><c>Pathname</c> can be a directory, a group of files or 
-          even a file. The <c>Pathname</c> string can contain wildcard(s). </p>
-        <p><c>ls/1</c> implies the user's current remote directory. </p>
-        <p>The format of <c>Listing</c> is operating system dependent 
-          (on UNIX it is typically produced from the output of the 
-          <c>ls -l</c> shell command).</p>
+        <p>Returns a list of files in long format.</p>
+        <p><c>Pathname</c> can be a directory, a group of files, or 
+           a file. The <c>Pathname</c> string can contain wildcards.</p>
+        <p><c>ls/1</c> implies the current remote directory of the user.</p>
+        <p>The format of <c>Listing</c> depends on the operating system. 
+          On UNIX, it is typically produced from the output of the 
+          <c>ls -l</c> shell command.</p>
 
        <marker id="mkdir"></marker>
       </desc>
@@ -499,7 +496,7 @@
 
     <func>
       <name>mkdir(Pid, Dir) -> ok | {error, Reason}</name>
-      <fsummary>Create remote directory.</fsummary>
+      <fsummary>Creates a remote directory.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Dir = string()</v>
@@ -525,15 +522,15 @@
         <v>Reason = restriction_reason() | common_reason()</v>
       </type>
       <desc>
-        <p>Returns a list of files in short format. </p>
-        <p><c>Pathname</c> can be a directory, a group of files or 
-          even a file. The <c>Pathname</c> string can contain wildcard(s). </p>
-        <p><c>nlist/1</c> implies the user's current remote directory. </p>
+        <p>Returns a list of files in short format.</p>
+        <p><c>Pathname</c> can be a directory, a group of files, or 
+           a file. The <c>Pathname</c> string can contain wildcards.</p>
+        <p><c>nlist/1</c> implies the current remote directory of the user.</p>
         <p>The format of <c>Listing</c> is a stream of
-          file names, where each name is separated by &lt;CRLF&gt; or
-          &lt;NL&gt;. Contrary to the <c>ls</c> function, the purpose of
-          <c>nlist</c> is to make it possible for a program to
-          automatically process file name information.</p>
+          filenames where each filename is separated by &lt;CRLF&gt; or
+          &lt;NL&gt;. Contrary to function <c>ls</c>, the purpose of
+          <c>nlist</c> is to enable a program to
+          process filename information automatically.</p>
 
        <marker id="open"></marker>
       </desc>
@@ -542,23 +539,23 @@
     <func>
       <name>open(Host) -> {ok, Pid} | {error, Reason}</name>
       <name>open(Host, Opts) -> {ok, Pid} | {error, Reason}</name>
-      <fsummary>Start an standalone ftp client.</fsummary>
+      <fsummary>Starts a standalone FTP client.</fsummary>
       <type>
 	<v>Host = string() | ip_address()</v>
 	<v>Opts = options()</v>
 	<v>options() = [option()]</v>
 	<v>option() = start_option() | open_option()</v>
 	<v>start_option() = {verbose, verbose()} | {debug, debug()}</v>
-	<v>verbose() = boolean() (defaults to false)</v>
-	<v>debug() = disable | debug | trace (defaults to disable)</v>
+	<v>verbose() = boolean() (default is false)</v>
+	<v>debug() = disable | debug | trace (default is disable)</v>
 	<v>open_option() = {ipfamily, ipfamily()} | {port, port()} | {mode, mode()} | {tls, tls_options()} | {timeout, timeout()} | {dtimeout, dtimeout()} | {progress, progress()}</v>
-	<v>ipfamily() = inet | inet6 | inet6fb4 (defaults to inet)</v>
-	<v>port() = integer() > 0 (defaults to 21)</v>
-	<v>mode() = active | passive (defaults to passive)</v>
+	<v>ipfamily() = inet | inet6 | inet6fb4 (default is inet)</v>
+	<v>port() = integer() > 0 (default is 21)</v>
+	<v>mode() = active | passive (default is passive)</v>
 	<v>tls_options() = [<seealso marker="ssl:ssl#type-ssloption">ssl:ssloption()</seealso>]</v>
-	<v>timeout() = integer() > 0 (defaults to 60000 milliseconds)</v>
-	<v>dtimeout() = integer() > 0 | infinity (defaults to infinity)</v>
-	<v>pogress() = ignore | {module(), function(), initial_data()} (defaults to ignore)</v>
+	<v>timeout() = integer() > 0 (default is 60000 milliseconds)</v>
+	<v>dtimeout() = integer() > 0 | infinity (default is infinity)</v>
+	<v>pogress() = ignore | {module(), function(), initial_data()} (default is ignore)</v>
 	<v>module() = atom()</v>
 	<v>function() = atom()</v>
 	<v>initial_data() = term()</v>
@@ -566,16 +563,20 @@
       </type>
 
       <desc>
-	<p>This function is used to start a standalone ftp client process 
-          (without the inets service framework) and 
-          open a session with the FTP server at <c>Host</c>. </p>
+	<p>Starts a standalone FTP client process 
+          (without the <c>Inets</c> service framework) and 
+          opens a session with the FTP server at <c>Host</c>. </p>
 
-	<p>If the option <c>{tls, tls_options()}</c> is present, the ftp session will be transported over tls (ftps, see 
-<url href="http://www.ietf.org/rfc/rfc4217.txt">RFC 4217</url>). The list <c>tls_options()</c> may be empty. The function <seealso marker="ssl:ssl#connect/3"><c>ssl:connect/3</c></seealso> is used for securing both the control connection and the data sessions.
+	<p>If option <c>{tls, tls_options()}</c> is present, the FTP session 
+	is transported over <c>tls</c> (<c>ftps</c>, see 
+	<url href="http://www.ietf.org/rfc/rfc4217.txt">RFC 4217</url>). 
+	The list <c>tls_options()</c> can be empty. The function 
+	<seealso marker="ssl:ssl#connect/3"><c>ssl:connect/3</c></seealso> 
+	is used for securing both the control connection and the data sessions.
 	</p>
 
-        <p>A session opened in this way, is closed using the 
-          <seealso marker="#close">close</seealso> function. </p>
+        <p>A session opened in this way is closed using function
+          <seealso marker="#close">close</seealso>.</p>
 
        <marker id="pwd"></marker>
       </desc>
@@ -583,22 +584,10 @@
 
     <func>
       <name>pwd(Pid) -> {ok, Dir} | {error, Reason}</name>
-      <fsummary>Get remote current working directory.</fsummary>
-      <type>
-	<v>Pid = pid()</v>
-	<v>Reason = restriction_reason() | common_reason() </v>
-      </type>
-      <desc>
-	<p>Returns the current working directory at the remote server. </p>
-      </desc>
-    </func>
-
-    <func>
-      <name>pwd(Pid) -> {ok, Dir} | {error, Reason}</name>
-      <fsummary>Get remote current working directory.</fsummary>
+      <fsummary>Gets the remote current working directory.</fsummary>
       <type>
         <v>Pid = pid()</v>
-        <v>Reason = restriction_reason() | common_reason() </v>
+        <v>Reason = restriction_reason() | common_reason()</v>
       </type>
       <desc>
         <p>Returns the current working directory at the remote server.</p>
@@ -612,7 +601,7 @@
     <func>
       <name>recv(Pid, RemoteFile) -> </name>
       <name>recv(Pid, RemoteFile, LocalFile) -> ok | {error, Reason}</name>
-      <fsummary>Transfer file from remote server.</fsummary>
+      <fsummary>Transfers a file from remote server.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>RemoteFile = LocalFile = string()</v>
@@ -620,14 +609,14 @@
         <v>file_write_error_reason() = see file:write/2</v>
       </type>
       <desc>
-        <p>Transfer the file <c>RemoteFile</c> from the remote server
-          to the the file system of the local client. If
+        <p>Transfers the file <c>RemoteFile</c> from the remote server
+          to the file system of the local client. If
           <c>LocalFile</c> is specified, the local file will be
-          <c>LocalFile</c>; otherwise it will be
+          <c>LocalFile</c>, otherwise
           <c>RemoteFile</c>.</p>
-        <p>If the file write fails
-          (e.g. enospc), then the command is aborted and <c>{error, file_write_error_reason()}</c> is returned. The file is
-          however <em>not</em> removed.</p>
+        <p>If the file write fails (for example, <c>enospc</c>), the command is 
+	aborted and <c>{error, file_write_error_reason()}</c> is returned. 
+	However, the file is <em>not</em> removed.</p>
 
        <marker id="recv_bin"></marker>
       </desc>
@@ -635,7 +624,7 @@
 
     <func>
       <name>recv_bin(Pid, RemoteFile) -> {ok, Bin} | {error, Reason}</name>
-      <fsummary>Transfer file from remote server as a binary.</fsummary>
+      <fsummary>Transfers a file from remote server as a binary.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Bin = binary()</v>
@@ -652,14 +641,14 @@
 
     <func>
       <name>recv_chunk_start(Pid, RemoteFile) -> ok | {error, Reason}</name>
-      <fsummary>Start chunk-reading of the remote file.</fsummary>
+      <fsummary>Starts chunk-reading of the remote file.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>RemoteFile = string()</v>
         <v>Reason = restriction_reason() | common_reason()</v>
       </type>
       <desc>
-        <p>Start transfer of the file <c>RemoteFile</c> from the
+        <p>Starts transfer of the file <c>RemoteFile</c> from the
           remote server.</p>
 
        <marker id="recv_chunk"></marker>
@@ -668,20 +657,20 @@
 
     <func>
       <name>recv_chunk(Pid) -> ok | {ok, Bin} | {error, Reason}</name>
-      <fsummary>Receive a chunk of the remote file.</fsummary>
+      <fsummary>Receives a chunk of the remote file.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Bin = binary()</v>
         <v>Reason = restriction_reason() | common_reason()</v>
       </type>
       <desc>
-        <p>Receive a chunk of the remote file (<c>RemoteFile</c> of 
-          <c>recv_chunk_start</c>). The return values has the following 
+        <p>Receives a chunk of the remote file (<c>RemoteFile</c> of 
+          <c>recv_chunk_start</c>). The return values have the following 
           meaning:</p>
         <list type="bulleted">
-          <item><c>ok</c> the transfer is complete.</item>
-          <item><c>{ok, Bin}</c> just another chunk of the file.</item>
-          <item><c>{error, Reason}</c> transfer failed.</item>
+          <item><c>ok</c> = the transfer is complete.</item>
+          <item><c>{ok, Bin}</c> = just another chunk of the file.</item>
+          <item><c>{error, Reason}</c> = transfer failed.</item>
         </list>
 
        <marker id="rename"></marker>
@@ -690,7 +679,7 @@
 
     <func>
       <name>rename(Pid, Old, New) -> ok | {error, Reason}</name>
-      <fsummary>Rename a file at the remote server..</fsummary>
+      <fsummary>Renames a file at the remote server.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>CurrFile = NewFile = string()</v>
@@ -705,7 +694,7 @@
 
     <func>
       <name>rmdir(Pid, Dir) -> ok | {error, Reason}</name>
-      <fsummary>Remove a remote directory.</fsummary>
+      <fsummary>Removes a remote directory.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Dir = string()</v>
@@ -723,7 +712,7 @@
     <func>
       <name>send(Pid, LocalFile) -></name>
       <name>send(Pid, LocalFile, RemoteFile) -> ok | {error, Reason}</name>
-      <fsummary>Transfer file to remote server.</fsummary>
+      <fsummary>Transfers a file to the remote server.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>LocalFile = RemoteFile = string()</v>
@@ -732,7 +721,7 @@
       <desc>
         <p>Transfers the file <c>LocalFile</c> to the remote server. If 
           <c>RemoteFile</c> is specified, the name of the remote file is set
-          to <c>RemoteFile</c>; otherwise the name is set to <c>LocalFile</c>.</p>
+          to <c>RemoteFile</c>, otherwise to <c>LocalFile</c>.</p>
 
        <marker id="send_bin"></marker>
       </desc>
@@ -740,7 +729,7 @@
 
     <func>
       <name>send_bin(Pid, Bin, RemoteFile) -> ok | {error, Reason}</name>
-      <fsummary>Transfer a binary into a remote file.</fsummary>
+      <fsummary>Transfers a binary into a remote file.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Bin = binary()()</v>
@@ -757,17 +746,17 @@
 
     <func>
       <name>send_chunk(Pid, Bin) -> ok | {error, Reason}</name>
-      <fsummary>Write a chunk to the remote file.</fsummary>
+      <fsummary>Writes a chunk to the remote file.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Bin = binary()</v>
         <v>Reason = echunk | restriction_reason() | common_reason()</v>
       </type>
       <desc>
-        <p>Transfer the chunk <c>Bin</c> to the remote server, which 
+        <p>Transfers the chunk <c>Bin</c> to the remote server, which 
           writes it into the file specified in the call to 
-          <c>send_chunk_start/2</c>. </p>
-        <p>Note that for some errors, e.g. file system full, it is 
+          <c>send_chunk_start/2</c>.</p>
+        <p>For some errors, for example, file system full, it is 
           necessary to to call <c>send_chunk_end</c> to get the 
           proper reason.</p>
 
@@ -777,14 +766,14 @@
 
     <func>
       <name>send_chunk_start(Pid, File) -> ok | {error, Reason}</name>
-      <fsummary>Start transfer of file chunks.</fsummary>
+      <fsummary>Starts transfer of file chunks.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>File = string()</v>
         <v>Reason = restriction_reason() | common_reason()</v>
       </type>
       <desc>
-        <p>Start transfer of chunks into the file <c>File</c> at the 
+        <p>Starts transfer of chunks into the file <c>File</c> at the 
           remote server.</p>
 
        <marker id="send_chunk_end"></marker>
@@ -793,7 +782,7 @@
 
     <func>
       <name>send_chunk_end(Pid) -> ok | {error, Reason}</name>
-      <fsummary>Stop transfer of chunks.</fsummary>
+      <fsummary>Stops transfer of chunks.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Reason = restriction_reason() | common_reason() | shortage_reason()</v>
@@ -809,7 +798,7 @@
 
     <func>
       <name>type(Pid, Type) -> ok | {error, Reason}</name>
-      <fsummary>Set transfer type to <c>ascii</c>or <c>binary</c>.</fsummary>
+      <fsummary>Sets transfer type to <c>ascii</c>or <c>binary</c>.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Type = ascii | binary</v>
@@ -817,8 +806,8 @@
       </type>
       <desc>
         <p>Sets the file transfer type to <c>ascii</c> or <c>binary</c>. When
-          an ftp session is opened, the default transfer type of the
-          server is used, most often <c>ascii</c>, which is the default
+          an FTP session is opened, the default transfer type of the
+          server is used, most often <c>ascii</c>, which is default
           according to <url href="http://www.ietf.org/rfc/rfc959.txt">RFC 959</url>.</p>
        <marker id="user3"></marker>
       </desc>
@@ -857,21 +846,22 @@
 
     <func>
       <name>quote(Pid, Command) -> [FTPLine]</name>
-      <fsummary>Sends an arbitrary FTP command. </fsummary>
+      <fsummary>Sends an arbitrary FTP command.</fsummary>
       <type>
         <v>Pid = pid()</v>
         <v>Command = string()</v>
-        <v>FTPLine = string() - Note the telnet end of line characters, from the ftp protocol definition, CRLF e.g. "\\r\\n" has been removed.</v>
-      </type>
-      <desc>
-        <p>Sends an arbitrary FTP command and returns verbatimly a list
-          of the lines sent back by the FTP server. This functions is
-          intended to give an application accesses to FTP commands
-          that are server specific or that may not be provided by
-          this FTP client. </p>
+        <v>FTPLine = string(</v>
+      </type>
+      <desc><note><p>The telnet end of line characters, from the FTP 
+      protocol definition, CRLF, for example, "\\r\\n" has been removed.</p></note>
+        <p>Sends an arbitrary FTP command and returns verbatim a list
+          of the lines sent back by the FTP server. This function is
+          intended to give application accesses to FTP commands
+          that are server-specific or that cannot be provided by
+          this FTP client.</p>
         <note>
-          <p>FTP commands that require a data connection can not be
-            successfully issued with this function. </p>
+          <p>FTP commands requiring a data connection cannot be
+            successfully issued with this function.</p>
         </note>
       </desc>
     </func>
@@ -885,30 +875,31 @@
     <taglist>
       <tag><c>echunk</c></tag>
       <item>
-        <p>Synchronisation error during chunk sending. 
-          </p>
-        <p>A call has been made to <c>send_chunk/2</c> or
-          <c>send_chunk_end/1</c>, before a call to
-          <c>send_chunk_start/2</c>; or a call has been made to another
-          transfer function during chunk sending, i.e. before a call
-          to <c>send_chunk_end/1</c>.</p>
+        <p>Synchronization error during chunk sending according to one 
+	of the following:
+          </p><list type="bulleted">
+	  <item>A call is made to <c>send_chunk/2</c> or <c>send_chunk_end/1</c>
+	  before a call to <c>send_chunk_start/2</c>.</item>
+	  <item>A call has been made to another transfer function during chunk 
+	  sending, that is, before a call to <c>send_chunk_end/1</c>.</item>
+           </list>
       </item>
       <tag><c>eclosed</c></tag>
       <item>
-        <p>The session has been closed.</p>
+        <p>The session is closed.</p>
       </item>
       <tag><c>econn</c></tag>
       <item>
-        <p>Connection to remote server prematurely closed.</p>
+        <p>Connection to the remote server is prematurely closed.</p>
       </item>
       <tag><c>ehost</c></tag>
       <item>
-        <p>Host not found, FTP server not found, or connection rejected
+        <p>Host is not found, FTP server is not found, or connection is rejected
           by FTP server.</p>
       </item>
       <tag><c>elogin</c></tag>
       <item>
-        <p>User not logged in.</p>
+        <p>User is not logged in.</p>
       </item>
       <tag><c>enotbinary</c></tag>
       <item>
@@ -925,7 +916,7 @@
       </item>
       <tag><c>euser</c></tag>
       <item>
-        <p>User name or password not valid.</p>
+        <p>Invalid username or password.</p>
       </item>
       <tag><c>etnospc</c></tag>
       <item>
@@ -938,14 +929,16 @@
       </item>
       <tag><c>efnamena</c></tag>
       <item>
-        <p>File name not allowed [553].</p>
+        <p>Filename not allowed [553].</p>
       </item>
     </taglist>
   </section>
 
   <section>
     <title>SEE ALSO</title>
-    <p>file, filename, J. Postel and J. Reynolds: File Transfer Protocol
+    <p><seealso marker="kernel:file">file(3)</seealso>
+       <seealso marker="stdlib:filename">filename(3)</seealso>
+       and J. Postel and J. Reynolds: File Transfer Protocol
       (<url href="http://www.ietf.org/rfc/rfc959.txt">RFC 959</url>).
       </p>
   </section>
diff --git a/lib/inets/doc/src/ftp_client.xml b/lib/inets/doc/src/ftp_client.xml
index 2f5b8abb5f..89e66db814 100644
--- a/lib/inets/doc/src/ftp_client.xml
+++ b/lib/inets/doc/src/ftp_client.xml
@@ -34,38 +34,24 @@
   </header>
 
   <section>
-    <title>Introduction</title>
+    <title>Getting Started</title>
 
-    <p>Ftp clients are consider to be rather temporary and are
-      for that reason only started and stopped during
-      runtime and can not be started at application startup.
-      Due to the design of FTP client API, letting some
-      functions return intermediate results, only the process
-      that started the ftp client will be able to access it in
-      order to preserve sane semantics. (This could be solved
-      by changing the API and using the concept of a controlling
-      process more in line with other OTP applications, but
-      that is perhaps something for the future.) 
-      If the process that started the ftp session 
-      dies the ftp client process will terminate.</p>
+    <p>FTP clients are considered to be rather temporary. Thus, 
+      they are only started and stopped during runtime and cannot 
+      be started at application startup.
+      The FTP client API is designed to allow some functions to 
+      return intermediate results. This implies that only the process
+      that started the FTP client can access it with
+      preserved sane semantics. 
+      If the process that started the FTP session 
+      dies, the FTP client process terminates.</p>
 
-    <p>The client supports ipv6 as long as the underlying mechanisms
-      also do so. </p>
+    <p>The client supports IPv6 as long as the underlying mechanisms
+      also do so.</p>
 
-    </section>
-
-  <section>
-    <title>Using the FTP Client API</title>
-    <p>The following is a simple example of an ftp session, where
+    <p>The following is a simple example of an FTP session, where
       the user <c>guest</c> with password <c>password</c> logs on to
-      the remote host <c>erlang.org</c>, and where the file
-      <c>appl.erl</c> is transferred from the remote to the local
-      host.  When the session is opened, the current directory at
-      the remote host is <c>/home/guest</c>, and <c>/home/fred</c>
-      at the local host. Before transferring the file, the current
-      local directory is changed to <c>/home/eproj/examples</c>, and
-      the remote directory is set to
-      <c>/home/guest/appl/examples</c>.</p>
+      the remote host <c>erlang.org</c>:</p>
     <code type="erl"><![CDATA[
       1> inets:start().
       ok
@@ -86,6 +72,14 @@
       9> inets:stop(ftpc, Pid).
       ok
     ]]></code>
+    <p> The file
+      <c>appl.erl</c> is transferred from the remote to the local
+      host.  When the session is opened, the current directory at
+      the remote host is <c>/home/guest</c>, and <c>/home/fred</c>
+      at the local host. Before transferring the file, the current
+      local directory is changed to <c>/home/eproj/examples</c>, and
+      the remote directory is set to
+      <c>/home/guest/appl/examples</c>.</p>
   </section>
 </chapter>
 
diff --git a/lib/inets/doc/src/http_client.xml b/lib/inets/doc/src/http_client.xml
index 5c42f72cec..f4d7b751ac 100644
--- a/lib/inets/doc/src/http_client.xml
+++ b/lib/inets/doc/src/http_client.xml
@@ -34,103 +34,91 @@
   </header>
 
   <section>
-    <title>Introduction</title>
+    <title>Configuration</title>
 
-    <p>The HTTP client default profile will be started when the inets
+      <p>The HTTP client default profile is started when the <c>Inets</c>
     application is started and is then available to all processes on
-    that erlang node. Other profiles may also be started at
+    that Erlang node. Other profiles can also be started at
     application startup, or profiles can be started and stopped
-    dynamically in runtime. Each client profile will spawn a new
-    process to handle each request unless there is a possibility to use
-    a persistent connection with or without pipelining.
-    The client will add a <c>host</c> header and an empty
+    dynamically in runtime. Each client profile spawns a new
+    process to handle each request, unless a persistent connection 
+    can be used with or without pipelining.
+    The client adds a <c>host</c> header and an empty
     <c>te</c> header if there are no such headers present in the request.</p>
 
-    <p>The client supports ipv6 as long as the underlying mechanisms also do
+    <p>The client supports IPv6 as long as the underlying mechanisms also do
       so.</p>
-  </section>
 
-  <section>
-    <title>Configuration</title>
-    <p> What to put in the erlang node application configuration file
-      in order to start a profile at application startup.</p>
+    <p>The following is to be put in the Erlang node application configuration file
+      to start a profile at application startup:</p>
     <pre>
-      [{inets, [{services, [{httpc, PropertyList}]}]}]
-    </pre>
-    <p>For valid properties see 
+      [{inets, [{services, [{httpc, PropertyList}]}]}]</pre>
+    <p>For valid properties, see 
     <seealso marker="httpc">httpc(3)</seealso>. </p>
   </section>
 
   <section>
-    <title>Using the HTTP Client API</title>
+    <title>Getting Started</title>
+    <p>Start <c>Inets</c>:</p>
     <code type="erl">
  1 > inets:start().
-      ok
-    </code>
-    <p> The following calls uses the default client profile.
-      Use the proxy "www-proxy.mycompany.com:8000",
-      but not for requests to localhost. This will apply to all subsequent
-      requests</p>
+      ok</code>
+    <p>The following calls use the default client profile.
+      Use the proxy <c>"www-proxy.mycompany.com:8000"</c>,
+      except from requests to localhost. This applies to all the
+      following requests.</p>
+      <p>Example:</p>
     <code type="erl">
       2 > httpc:set_options([{proxy, {{"www-proxy.mycompany.com", 8000},
       ["localhost"]}}]).
-      ok
-    </code>
-    <p>An ordinary synchronous request. </p>
+      ok</code>
+    <p>The following is an ordinary synchronous request:</p>
     <code type="erl">
       3 > {ok, {{Version, 200, ReasonPhrase}, Headers, Body}} =
-      httpc:request(get, {"http://www.erlang.org", []}, [], []).
-    </code>
-    <p>With all default values, as above, a get request can also be written
-      like this.</p>
+      httpc:request(get, {"http://www.erlang.org", []}, [], []).</code>
+    <p>With all the default values presented, a get request can also be written
+      as follows:</p>
     <code type="erl">
       4 > {ok, {{Version, 200, ReasonPhrase}, Headers, Body}} =
-      httpc:request("http://www.erlang.org").
-    </code>
-    <p>An ordinary asynchronous request. The result will be sent
-      to the calling process in the form <c>{http, {ReqestId, Result}}</c></p>
+      httpc:request("http://www.erlang.org").</code>
+    <p>The following is an ordinary asynchronous request:</p>
     <code type="erl">
       5 > {ok, RequestId} =
-      httpc:request(get, {"http://www.erlang.org", []}, [], [{sync, false}]).
-    </code>
-    <p>In this case the calling process is the shell, so we receive the
-      result.</p>
+      httpc:request(get, {"http://www.erlang.org", []}, [], [{sync, false}]).</code>
+      <p>The result is sent to the calling process as
+      <c>{http, {ReqestId, Result}}</c>.</p>
+    <p>In this case, the calling process is the shell, so the following
+      result is received:</p>
     <code type="erl">
       6 > receive {http, {RequestId, Result}} -> ok after 500 -> error end.
-      ok
-    </code>
-    <p>Send a request with a specified connection header. </p>
+      ok</code>
+    <p>This sends a request with a specified connection header:</p>
     <code type="erl">
       7 > {ok, {{NewVersion, 200, NewReasonPhrase}, NewHeaders, NewBody}} =
       httpc:request(get, {"http://www.erlang.org", [{"connection", "close"}]},
-      [], []).
-    </code>
+      [], []).</code>
 
-    <p>Start a HTTP client profile. </p>
+    <p>Start an HTTP client profile:</p>
    
     <code><![CDATA[
       8 > {ok, Pid} = inets:start(httpc, [{profile, foo}]).
       {ok, <0.45.0>}       
       ]]></code>
     
-    <p>The new profile has no proxy settings so the connection will
-      be refused</p>
+    <p>The new profile has no proxy settings, so the connection is refused:</p>
       <code type="erl">
       9 > httpc:request("http://www.erlang.org", foo). 
-      {error, econnrefused}
-    </code>
+      {error, econnrefused}</code>
 
-    <p>Stop a HTTP client profile. </p>
+    <p>Stop the HTTP client profile:</p>
     <code type="erl">
       10 > inets:stop(httpc, foo).
-      ok
-    </code>
+      ok</code>
     
-    <p>Alternatively:</p>
+    <p>Alternative way to stop the HTTP client profile:</p>
     <code type="erl">
       10 > inets:stop(httpc, Pid).
-      ok
-    </code>
+      ok</code>
     
   </section>
 </chapter>
diff --git a/lib/inets/doc/src/http_server.xml b/lib/inets/doc/src/http_server.xml
index 51ed826c7c..4b6d64fc8f 100644
--- a/lib/inets/doc/src/http_server.xml
+++ b/lib/inets/doc/src/http_server.xml
@@ -22,7 +22,7 @@
 
     </legalnotice>
 
-    <title>HTTP server </title>
+    <title>HTTP server</title>
     <prepared>Ingela Anderton Andin</prepared>
     <responsible></responsible>
     <docno></docno>
@@ -36,62 +36,65 @@
   </header>
 
   <section>
-    <title>Introduction</title>
-    
+    <title>Configuration</title>
+    <marker id="config"></marker>
     <p>The HTTP server, also referred to as httpd, handles HTTP requests
-      as described in RFC 2616 with a few exceptions such as gateway
-      and proxy functionality. The server supports ipv6 as long as the
-      underlying mechanisms also do so. </p>
-
-    <p>The server implements numerous features such as SSL (Secure Sockets
-      Layer), ESI (Erlang Scripting Interface), CGI (Common Gateway
-      Interface), User Authentication(using Mnesia, dets or plain text
-      database), Common Logfile Format (with or without disk_log(3)
-      support), URL Aliasing, Action Mappings, and Directory Listings</p>
-
-    <p>The configuration of the server is provided as an erlang
-      property list, and for backwards compatibility also a configuration
+      as described in 
+      <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>
+      with a few exceptions, such as gateway
+      and proxy functionality. The server supports IPv6 as long as the
+      underlying mechanisms also do so.</p>
+
+    <p>The server implements numerous features, such as:</p>
+      <list type="bulleted">
+       <item>Secure Sockets Layer (SSL)</item>
+       <item>Erlang Scripting Interface (ESI)</item>
+       <item>Common Gateway Interface (CGI)</item>
+       <item>User Authentication (using <c>Mnesia</c>, 
+       <c>Dets</c> or plain text database)</item>
+       <item>Common Logfile Format (with or without disk_log(3) support)</item>
+       <item>URL Aliasing</item>
+       <item>Action Mappings</item>
+       <item>Directory Listings</item>
+      </list>
+
+    <p>The configuration of the server is provided as an Erlang
+      property list. For backwards compatibility, a configuration
       file using apache-style configuration directives is
       supported.</p>
 
-    <p>As of inets version 5.0 the HTTP server is an easy to
-      start/stop and customize web server that provides the most basic
-      web server functionality. Depending on your needs there 
-      are also other erlang based web servers that may be of interest
-      such as Yaws, http://yaws.hyber.org, that for instance has its own
-      markup support to generate html, and supports certain buzzword
-      technologies such as SOAP.</p>
+    <p>As of <c>Inets</c> 5.0 the HTTP server is an easy to
+      start/stop and customize web server providing the most basic
+      web server functionality. Depending on your needs, there 
+      are also other Erlang-based web servers that can be of interest
+      such as <url href=" http://yaws.hyber.org ">Yaws</url>, which,
+      for example, has its own
+      markup support to generate HTML and supports certain buzzword
+      technologies, such as SOAP.</p>
     
-    <p>Allmost all server functionality has been implemented using an
-      especially crafted server API which is described in the Erlang Web
-      Server API. This API can be used to advantage by all who wish
+    <p>Almost all server functionality has been implemented using an
+      especially crafted server API, which is described in the Erlang Web
+      Server API. This API can be used
       to enhance the core server functionality, for example with custom
       logging and authentication.</p>
 
-    <marker id="config"></marker>
-  </section>
-  
-  <section>
-    <title>Configuration</title>
-    
-    <p> What to put in the erlang node application configuration file
-      in order to start a http server at application startup.</p>
+    <p>The following is to be put in the Erlang node application configuration 
+      file to start an HTTP server at application startup:</p>
     
     <code type="erl">
       [{inets, [{services, [{httpd, [{proplist_file,
                  "/var/tmp/server_root/conf/8888_props.conf"}]},
                 {httpd, [{proplist_file,
-                 "/var/tmp/server_root/conf/8080_props.conf"}]}]}]}].
-    </code>
-
-    <p>The server is configured using an erlang property list.
-      For the available properties see
-      <seealso marker="httpd">httpd(3)</seealso>
-      For backwards compatibility also apache-like config files
-      are supported.
+                 "/var/tmp/server_root/conf/8080_props.conf"}]}]}]}].</code>
+
+    <p>The server is configured using an Erlang property list.
+      For the available properties, see
+      <seealso marker="httpd">httpd(3)</seealso>.
+      For backwards compatibility, apache-like configuration files
+      are also supported.
     </p>
     
-    <p>All possible config properties are as follows </p>
+    <p>The available configuration properties are as follows:</p>
     <code type="none">
      httpd_service() -> {httpd, httpd()}
      httpd()         -> [httpd_config()] 
@@ -103,40 +106,43 @@
      debug_options() -> {all_functions, modules()} | 
                         {exported_functions, modules()} |
                         {disable, modules()}
-     modules()       -> [atom()]
-    </code>
-    <p>{proplist_file, file()} File containing an erlang property
+     modules()       -> [atom()]</code>
+     <p>Here:</p>
+     <taglist>
+       <tag><c>{file, file()}</c></tag>
+       <item><p>If you use an old apace-like configuration file.</p></item>
+       <tag><c>{proplist_file, file()}</c></tag>
+       <item><p>File containing an Erlang property
       list, followed by a full stop, describing the HTTP server
-      configuration.</p>
-    <p>{file, file()} If you use an old apace-like configuration file.</p>
-    <p>{debug, debug()} - Can enable trace on all
-      functions or only exported functions on chosen modules.</p>
-    <p>{accept_timeout, integer()} sets the wanted timeout value for
-      the server to set up a request connection.</p>
-
-    <marker id="using_http_server_api"></marker>
+      configuration.</p></item> 
+       <tag><c>{debug, debug()}</c></tag>
+       <item><p>Can enable trace on all functions or only exported functions 
+       on chosen modules.</p></item>
+       <tag><c>{accept_timeout, integer()}</c></tag>
+       <item><p>Sets the wanted time-out value for
+      the server to set up a request connection.</p></item>
+     </taglist>
   </section>
 
   <section>
-    <title>Using the HTTP Server API</title>
+    <title>Getting Started</title>
+    <marker id="using_http_server_api"></marker>
+    <p>Start <c>Inets</c>:</p>
     <code type="none">
       1 > inets:start().
-      ok
-    </code>
-    <p> Start a HTTP server with minimal
-      required configuration. Note that if you
-      specify port 0 an arbitrary available port will be
-      used and you can use the info function to find out
-      which port number that was picked.
-    </p>
+      ok</code>
+    <p>Start an HTTP server with minimal required configuration.
+       If you specify port <c>0</c>, an arbitrary available port is
+       used, and you can use function <c>info</c> to find which port 
+       number that was picked:</p>
 
     <code type="none">
       2 > {ok, Pid} = inets:start(httpd, [{port, 0},
       {server_name,"httpd_test"}, {server_root,"/tmp"},
       {document_root,"/tmp/htdocs"}, {bind_address, "localhost"}]).
-      {ok, 0.79.0}      
-    </code>
+      {ok, 0.79.0}      </code>
     
+      <p>Call <c>info</c>:</p>
     <code type="none">
       3 >  httpd:info(Pid).
       [{mime_types,[{"html","text/html"},{"htm","text/html"}]},
@@ -144,336 +150,324 @@
       {bind_address, {127,0,0,1}},
       {server_root,"/tmp"},
       {port,59408},
-      {document_root,"/tmp/htdocs"}]
-    </code>
+      {document_root,"/tmp/htdocs"}]</code>
 
-    <p> Reload the configuration without restarting the server.
-      Note port and bind_address can not be changed. Clients
-      trying to access the server during the reload will
-      get a service temporary unavailable answer.
+    <p>Reload the configuration without restarting the server:
+      
     </p>
     <code type="none">
     4 > httpd:reload_config([{port, 59408},
       {server_name,"httpd_test"}, {server_root,"/tmp/www_test"},
       {document_root,"/tmp/www_test/htdocs"},
       {bind_address, "localhost"}], non_disturbing).
-    ok.
-    </code>
+    ok.</code>
+
+    <note><p><c>port</c> and <c>bind_address</c> cannot be changed. 
+      Clients trying to access the server during the reload
+      get a service temporary unavailable answer.</p></note>
 
     <code type="none">
       5 >  httpd:info(Pid, [server_root, document_root]).
-      [{server_root,"/tmp/www_test"},{document_root,"/tmp/www_test/htdocs"}] 
-    </code>
+      [{server_root,"/tmp/www_test"},{document_root,"/tmp/www_test/htdocs"}] </code>
 
     <code type="none">
-      6 > ok = inets:stop(httpd, Pid).
-    </code>
+      6 > ok = inets:stop(httpd, Pid).</code>
     
-    <p> Alternative:</p>
+    <p>Alternative:</p>
     
     <code type="none">
-      6 > ok = inets:stop(httpd, {{127,0,0,1}, 59408}).
-    </code>
+      6 > ok = inets:stop(httpd, {{127,0,0,1}, 59408}).</code>
 
-    <p>Note that bind_address has to be
-      the ip address reported by the info function and can
-      not be the hostname that is allowed when inputting bind_address.</p>
-    
-    <marker id="htaccess"></marker>
+    <p>Notice that <c>bind_address</c> must be the IP address reported 
+    by function <c>info</c> and cannot be the hostname that is allowed 
+    when putting in <c>bind_address</c>.</p>
   </section>
 
   <section>
-    <title>Htaccess - User Configurable Authentication.</title>
-    <p>If users of the web server needs to manage authentication of
-        web pages that are local to their user and do not have
-        server administrative privileges. They can use the
-        per-directory runtime configurable user-authentication scheme
-        that Inets calls htaccess. It works the following way: </p>
+    <title>Htaccess - User Configurable Authentication</title>
+    <marker id="htaccess"></marker>
+    <p>Web server users without server administrative privileges
+        that need to manage authentication of web pages that are local 
+	to their user can use the per-directory runtime configurable 
+	user-authentication scheme <c>htaccess</c>. 
+        It works as follows:</p>
       <list type="bulleted">
         <item>Each directory in the path to the requested asset is
-         searched for an access-file (default .htaccess), that restricts
-         the web servers rights to respond to a request. If an access-file
-         is found the rules in that file is applied to the
-         request. </item>
-        <item>The rules in an access-file applies both to files in the same
-         directories and in subdirectories. If there exists more than one
-         access-file in the path to an asset, the rules in the
-         access-file nearest the requested asset will be applied.</item>
-        <item>To change the rules that restricts the use of 
-         an asset. The user only needs to have write access 
-         to the directory where the asset exists.</item>
-        <item>All the access-files in the path to a requested asset is read
-         once per request, this means that the load on the server will
-         increase when this scheme is used.</item>
-        <item>If a directory is
-         limited both by auth directives in the HTTP server configuration
-         file and by the htaccess files. The user must be allowed to get
-         access the file by both methods for the request to succeed.</item>
+         searched for an access file (default is <c>.htaccess</c>), which 
+	 restricts the web servers rights to respond to a request. 
+	 If an access file is found, the rules in that file is applied to the
+         request.</item>
+        <item>The rules in an access file apply to files in the same
+         directory and in subdirectories. If there exists more than one
+         access file in the path to an asset, the rules in the
+         access file nearest the requested asset is applied.</item>
+        <item>To change the rules that restrict the use of 
+         an asset, the user only needs write access 
+         to the directory where the asset is.</item>
+        <item>All access files in the path to a requested asset are read
+         once per request. This means that the load on the server
+         increases when <c>htaccess</c> is used.</item>
+        <item>If a directory is limited both by authentication directives 
+	 in the HTTP server configuration file and by the <c>htaccess</c> 
+	 files, the user must be allowed to get access to the file by both 
+	 methods for the request to succeed.</item>
       </list>
 
     <section>
       <title>Access Files Directives</title>
-        <p>In every directory under the <c>DocumentRoot</c> or under an
-	<c>Alias</c> a user can place an access-file. An access-file
-	is a plain text file that specify the restrictions that
-	shall be considered before the web server answer to a
-          request. If there are more than one access-file in the path
-          to the requested asset, the directives in the access-file in
-          the directory nearest the asset will be used.</p>
-        <list type="bulleted">
+        <p>In every directory under <c>DocumentRoot</c> or under an
+	<c>Alias</c> a user can place an access file. An access file
+	is a plain text file that specifies the restrictions to
+	consider before the web server answers to a
+          request. If there are more than one access file in the path
+          to the requested asset, the directives in the access file in
+          the directory nearest the asset is used.</p>
+        <taglist>
+	  <tag><em>"allow"</em></tag>
           <item>
-            <p><em>DIRECTIVE: "allow"</em></p>
-            <p><em>Syntax:</em><c>Allow</c> from subnet subnet|from all              <br></br>
-<em>Default:</em><c>from all </c>              <br></br>
-</p>
-            <p>Same as the directive allow for the server config file. </p>
+	    <p><em>Syntax:</em> <c>Allow</c> from subnet <c>subnet | from all</c></p>
+	    <p><em>Default:</em> <c>from all</c></p>
+            <p>Same as directive <c>allow</c> for the server configuration file.</p>
           </item>
-          <item>
-            <p><em>DIRECTIVE: "AllowOverRide"</em></p>
-            <p><em>Syntax:</em><c>AllowOverRide</c> all | none |
-              Directives              <br></br>
-<em>Default:</em><c>- None -</c>              <br></br>
-<c>AllowOverRide</c> Specify which parameters that not 
-              access-files in subdirectories are allowed to alter the value 
-              for. If the parameter is set to none no more 
-              access-files will be parsed. 
+	  <tag><em>"AllowOverRide"</em></tag>
+          <item>  
+            <p><em>Syntax:</em> <c>AllowOverRide</c> <c>all | none | Directives</c></p>
+	    <p><em>Default:</em> <c>none</c></p>
+	    <p><c>AllowOverRide</c> specifies the parameters that
+              access files in subdirectories are not allowed to alter the value 
+              for. If the parameter is set to <c>none</c>, no further 
+              access files is parsed.
               </p>
-            <p>If only one access-file exists setting this parameter to
-              none can lessen the burden on the server since the server
-              will stop looking for access-files.</p>
+            <p>If only one access file exists, setting this parameter to
+              <c>none</c> can ease the burden on the server as the server
+              then stops looking for access files.</p>
           </item>
+	  <tag><em>"AuthGroupfile"</em></tag>
           <item>
-            <p><em>DIRECTIVE: "AuthGroupfile"</em></p>
-            <p><em>Syntax:</em><c>AuthGroupFile</c> Filename              <br></br>
-<em>Default:</em><c>- None -</c>              <br></br>
-</p>
-            <p>AuthGroupFile indicates which file that contains the list
-              of groups.  Filename must contain the absolute path to the
-              file.  The format of the file is one group per row and
+            <p><em>Syntax:</em> <c>AuthGroupFile</c> Filename</p>
+	    <p><em>Default:</em> <c>none</c></p>
+            <p><c>AuthGroupFile</c> indicates which file that contains the list
+              of groups. The filename must contain the absolute path to the
+              file. The format of the file is one group per row and
               every row contains the name of the group and the members
-              of the group separated by a space, for example:</p>
+              of the group, separated by a space, for example:</p>
             <pre>
-GroupName: Member1 Member2 .... MemberN
-            </pre>
+GroupName: Member1 Member2 .... MemberN</pre>
           </item>
+	  <tag><em>"AuthName"</em></tag>
           <item>
-            <p><em>DIRECTIVE: "AuthName"</em></p>
-            <p><em>Syntax:</em><c>AuthName</c> auth-domain              <br></br>
-<em>Default:</em><c>- None -</c>              <br></br>
-</p>
-            <p>Same as the directive AuthName for the server config file. </p>
+            <p><em>Syntax:</em> <c>AuthName</c> auth-domain</p>
+	    <p><em>Default:</em> <c>none</c></p>
+            <p>Same as directive <c>AuthName</c> for the server 
+	    configuration file.</p>
           </item>
+	  <tag><em>"AuthType"</em></tag>
           <item>
-            <p><em>DIRECTIVE: "AuthType"</em></p>
-            <p><em>Syntax:</em><c>AuthType</c> Basic              <br></br>
-<em>Default:</em><c>Basic</c>              <br></br>
-</p>
-            <p><c>AuthType</c> Specify which authentication scheme that shall
-              be used. Today only Basic Authenticating using UUEncoding of
-              the password and user ID is implemented.  </p>
+            <p><em>Syntax:</em> <c>AuthType</c> <c>Basic</c></p>
+	    <p><em>Default:</em> <c>Basic</c></p>
+            <p><c>AuthType</c> specifies which authentication scheme to
+              be used. Only Basic Authenticating using UUEncoding of
+              the password and user ID is implemented.</p>
           </item>
+	  <tag><em>"AuthUserFile"</em></tag>
           <item>
-            <p><em>DIRECTIVE: "AuthUserFile"</em></p>
-            <p><em>Syntax:</em><c>AuthUserFile</c> Filename              <br></br>
-<em>Default:</em><c>- None -</c>              <br></br>
-</p>
-            <p><c>AuthUserFile</c> indicate which file that contains the list
-              of users.  Filename must contain the absolute path to the
-              file. The users name and password are not encrypted so do not
+            <p><em>Syntax:</em> <c>AuthUserFile</c> Filename</p>
+	    <p><em>Default:</em><c>none</c></p>
+            <p><c>AuthUserFile</c> indicates which file that contains the list
+              of users. The filename must contain the absolute path to the
+              file. The username and password are not encrypted so do not
               place the file with users in a directory that is accessible
-              via the web server. The format of the file is one user per row
-              and every row contains User Name and Password separated by a
-              colon, for example:</p>
+              through the web server. The format of the file is one user per row.
+              Every row contains <c>UserName</c> and <c>Password</c> separated 
+	      by a colon, for example:</p>
             <pre>
 UserName:Password
-UserName:Password
-            </pre>
+UserName:Password</pre>
           </item>
+	  <tag><em>"deny"</em></tag>
           <item>
-            <p><em>DIRECTIVE: "deny"</em></p>
-            <p><em>Syntax:</em><c>deny</c> from subnet subnet|from all              <br></br>
-<em>Context:</em> Limit</p>
-            <p>Same as the directive deny for the server config file. </p>
+            <p><em>Syntax:</em> <c>deny</c> from subnet <c>subnet | from all</c></p>
+	    <p><em>Context:</em> Limit</p>
+            <p>Same as directive <c>deny</c> for the server configuration file.</p>
           </item>
-          <item>
-            <p><em>DIRECTIVE: "Limit"</em>              <br></br>
-</p>
-            <p><em>Syntax:</em><c><![CDATA[<Limit]]></c> RequestMethods<c>></c>              <br></br>
-<em>Default:</em> - None -              <br></br>
-</p>
-            <p><c><![CDATA[<Limit>]]></c> and &lt;/Limit&gt; are used to enclose
-              a group of directives which applies only to requests using
-              the specified methods. If no request method is specified
+	  <tag><em>"Limit"</em></tag>
+          <item> 
+            <p><em>Syntax:</em> <c><![CDATA[<Limit]]></c> RequestMethods<c>></c></p>
+	    <p><em>Default:</em> <c>none</c></p>
+            <p><c><![CDATA[<Limit>]]></c> and <c>&lt;/Limit&gt;</c> are used to enclose
+              a group of directives applying only to requests using
+              the specified methods. If no request method is specified,
               all request methods are verified against the restrictions.</p>
+	      <p>Example:</p>
             <pre>
 &lt;Limit POST GET HEAD&gt;
   order allow deny
   require group group1
   allow from 123.145.244.5
-&lt;/Limit&gt;
-            </pre>
+&lt;/Limit&gt;</pre>
           </item>
-          <item>
-            <p><em>DIRECTIVE: "order"</em>              <br></br>
-<em>Syntax:</em><c>order</c> allow deny | deny allow              <br></br>
-<em>Default:</em> allow deny              <br></br>
-</p>
-            <p><c>order</c>, defines if the deny or allow control shall
-              be preformed first.</p>
-            <p>If the order is set to allow deny, then first the users
-              network address is controlled to be in the allow subset. If
-              the users network address is not in the allowed subset he will
-              be denied to get the asset. If the network-address is in the
-              allowed subset then a second control will be preformed, that
-              the users network address is not in the subset of network
-              addresses that shall be denied as specified by the deny
-              parameter.</p>
-            <p>If the order is set to deny allow then only users from networks
-              specified to be in the allowed subset will succeed to request  
+	  <tag><em>"order"</em></tag>
+          <item>   
+	    <p><em>Syntax:</em> <c>order</c> <c>allow deny | deny allow</c></p>
+	    <p><em>Default:</em> <c>allow deny</c></p>
+            <p><c>order</c> defines if the deny or allow control is to
+              be performed first.</p>
+            <p>If the order is set to <c>allow deny</c>, the users
+              network address is first controlled to be in the allow subset. 
+	      If the user network address is not in the allowed subset, the user
+              is denied to get the asset. If the network address is in the
+              allowed subset, a second control is performed. That is,
+              the user network address is not in the subset of network
+              addresses to be denied as specified by parameter <c>deny</c>.</p>
+            <p>If the order is set to <c>deny allow</c>, only users from networks
+              specified to be in the allowed subset succeeds to request  
               assets in the limited area.</p>
           </item>
-          <item>
-            <p><em>DIRECTIVE: "require"</em></p>
-            <p><em>Syntax:</em><c>require</c>
-              group group1 group2...|user user1 user2...              <br></br>
-<em>Default:</em><c>- None -</c>              <br></br>
-<em>Context:</em> Limit              <br></br>
-</p>
-            <p>See the require directive in the documentation of mod_auth(3)
-              for more information.</p>
+	  <tag><em>"require"</em></tag>
+          <item> 
+            <p><em>Syntax:</em> <c>require</c>
+              <c>group group1 group2... | user user1 user2...</c></p>
+	      <p><em>Default:</em> <c>none</c></p>
+	      <p><em>Context:</em> Limit</p>
+            <p>For more information, see directive <c>require</c>  in
+	    <seealso marker="mod_auth">mod_auth(3)</seealso>.</p>
           </item>
-        </list>
+        </taglist>
       </section>
-
-      <marker id="dynamic_we_pages"></marker>
     </section>
   
     <section>
       <title>Dynamic Web Pages</title>
-      <p>The Inets HTTP server provides two ways of creating dynamic web
-        pages, each with its own advantages and disadvantages. </p>
-      <p>First there are CGI-scripts that can be written in any programming
-        language. CGI-scripts are standardized and supported by most
-        web servers. The drawback with CGI-scripts is that they are resource
-        intensive because of their design. CGI requires the server to fork a
-        new OS process for each executable it needs to start. </p>
-      <p>Second there are ESI-functions that provide a tight and efficient
-        interface to the execution of Erlang functions, this interface
-        on the other hand is Inets specific. </p>
-
+      <marker id="dynamic_we_pages"></marker>
+      <p><c>Inets</c> HTTP server provides two ways of creating dynamic web
+        pages, each with its own advantages and disadvantages:</p>
+	<taglist>
+       <tag><em>CGI scripts</em></tag>
+       <item><p>Common Gateway Interface (CGI) scripts can be written 
+       in any programming language. CGI scripts are standardized and 
+       supported by most web servers. The drawback with CGI scripts is that 
+       they are resource-intensive because of their design. CGI requires the 
+       server to fork a new OS process for each executable it needs to start.
+       </p></item>
+       <tag><em>ESI-functions</em></tag>
+       <item><p>Erlang Server Interface (ESI) functions provide a tight and efficient
+        interface to the execution of Erlang functions. This interface,
+        on the other hand, is <c>Inets</c> specific.</p></item>
+     </taglist>
+      
       <section>
-        <title>The Common Gateway Interface (CGI) Version 1.1, RFC 3875.</title>
-        <p>The mod_cgi module makes it possible to execute CGI scripts
-          in the server.  A file that matches the definition of a
-          ScriptAlias config directive is treated as a CGI script.  A CGI
+        <title>CGI Version 1.1,
+	<url href="http://www.ietf.org/rfc/rfc3875.txt">RFC 3875</url></title>
+        <p>The module <c>mod_cgi</c> enables execution of CGI scripts
+          on the server. A file matching the definition of a
+          ScriptAlias config directive is treated as a CGI script. A CGI
           script is executed by the server and its output is returned to
-          the client. </p>
-        <p>The CGI Script response comprises a message-header and a
-          message-body, separated by a blank line.  The message-header
-          contains one or more header fields. The body may be
-          empty. Example: </p>
+          the client.</p>
+        <p>The CGI script response comprises a message header and a
+          message body, separated by a blank line. The message header
+          contains one or more header fields. The body can be
+          empty.</p>
+	 <p>Example:</p>
       
       <code>"Content-Type:text/plain\nAccept-Ranges:none\n\nsome very
-	plain text" </code>
+	plain text"</code>
       
-        <p>The server will interpret the cgi-headers and most of them
-          will be transformed into HTTP headers and sent back to the
-          client together with the body.</p>
-        <p>Support for CGI-1.1 is implemented in accordance with the RFC
-          3875. </p>
+        <p>The server interprets the message headers and most of them
+          are transformed into HTTP headers and sent back to the
+          client together with the message-body.</p>
+        <p>Support for CGI-1.1 is implemented in accordance with 
+	<url href="http://www.ietf.org/rfc/rfc3875.txt">RFC 3875</url>.</p>
       </section>
 
       <section>
-        <title>Erlang Server Interface (ESI)</title>
-        <p>The erlang server interface is implemented by the
-          module mod_esi.</p>
+        <title>ESI</title>
+        <p>The Erlang server interface is implemented by
+          module <c>mod_esi</c>.</p>
 
         <section>
-          <title>ERL Scheme </title>
+          <title>ERL Scheme</title>
           <p>The erl scheme is designed to mimic plain CGI, but without
-            the extra overhead. An URL which calls an Erlang erl function
+            the extra overhead. An URL that calls an Erlang <c>erl</c> function
             has the following syntax (regular expression): </p>
           <code type="none">
-http://your.server.org/***/Module[:/]Function(?QueryString|/PathInfo)
-          </code>
-          <p>*** above depends on how the ErlScriptAlias config
-            directive has been used</p>
-          <p>The module (Module) referred to must be found in the code
-            path, and it must define a function (Function) with an arity
-            of two or three. It is preferable to implement a funtion
-            with arity three as it permits you to send chunks of the
-            webpage beeing generated to the client during the generation
+http://your.server.org/***/Module[:/]Function(?QueryString|/PathInfo)</code>
+          <p>*** depends on how the ErlScriptAlias config
+            directive has been used.</p>
+          <p>The module <c>Module</c> referred to must be found in the code
+            path, and it must define a function <c>Function</c> with an arity
+            of two or three. It is preferable to implement a function
+            with arity three, as it permits to send chunks of the
+            web page to the client during the generation
             phase instead of first generating the whole web page and
             then sending it to the client. The option to implement a
             function with arity two is only kept for
             backwards compatibility reasons.
-            See <seealso marker="mod_esi">mod_esi(3)</seealso> for 
-            implementation details of the esi callback function.</p>
+            For implementation details of the ESI callback function, 
+	    see <seealso marker="mod_esi">mod_esi(3)</seealso>.</p>
         </section>
 
         <section>
-          <title>EVAL Scheme </title>
+          <title>EVAL Scheme</title>
           <p>The eval scheme is straight-forward and does not mimic the
-            behavior of plain CGI. An URL which calls an Erlang eval
+            behavior of plain CGI. An URL that calls an Erlang <c>eval</c>
             function has the following syntax:</p>
           <code type="none">
-http://your.server.org/***/Mod:Func(Arg1,...,ArgN)
-          </code>
-          <p>*** above depends on how the ErlScriptAlias config
-            directive has been used</p>
-          <p>The module (Mod) referred to must be found in the code
-            path, and data returned by the function (Func) is passed
+http://your.server.org/***/Mod:Func(Arg1,...,ArgN)</code>
+          <p>*** depends on how the ErlScriptAlias config
+            directive has been used.</p>
+          <p>The module <c>Mod</c> referred to must be found in the code
+            path and data returned by the function <c>Func</c> is passed
             back to the client. Data returned from the
-            function must furthermore take the form as specified in
-            the CGI specification. See <seealso marker="mod_esi">mod_esi(3)</seealso> for implementation details of the esi
-            callback function.</p>
+            function must take the form as specified in
+            the CGI specification. For implementation details of the ESI 
+	    callback function, 
+	    see <seealso marker="mod_esi">mod_esi(3)</seealso>.</p>
           <note>
             <p>The eval scheme can seriously threaten the
-              integrity of the Erlang node housing a Web server, for
-              example: </p>
+              integrity of the Erlang node housing a web server, for
+              example:</p>
             <code type="none">
-http://your.server.org/eval?httpd_example:print(atom_to_list(apply(erlang,halt,[])))
-            </code>
-            <p>which effectively will close down the Erlang node,
-              therefor, use the erl scheme instead, until this
-              security breach has been fixed.</p>
-            <p>Today there are no good way of solving this problem
-              and therefore Eval Scheme may be removed in future
-              release of Inets.  </p>
+http://your.server.org/eval?httpd_example:print(atom_to_list(apply(erlang,halt,[])))</code>
+            <p>This effectively closes down the Erlang node.
+              Therefore, use the erl scheme instead, until this
+              security breach is fixed.</p>
+            <p>Today there are no good ways of solving this problem
+              and therefore the eval scheme can be removed in future
+              release of <c>Inets</c>.</p>
           </note>
         </section>
       </section>
-
-      <marker id="logging"></marker>
     </section>
 
   <section>
-    <title>Logging </title>
-    <p>There are three types of logs supported. Transfer logs,
-      security logs and error logs.  The de-facto standard Common
+    <title>Logging</title>
+    <marker id="logging"></marker>
+    <p>Three types of logs are supported: transfer logs,
+      security logs, and error logs. The de-facto standard Common
         Logfile Format is used for the transfer and security logging.
       There are numerous statistics programs available to analyze Common
       Logfile Format. The Common Logfile Format looks as follows:
         </p>
     <p><em>remotehost rfc931 authuser [date] "request" status bytes</em></p>
+    <p>Here:</p>
     <taglist>
       <tag><em>remotehost</em></tag>
-      <item>Remote hostname</item>
+      <item>Remote hostname.</item>
       <tag><em>rfc931</em></tag>
-        <item>The client's remote username (RFC 931).</item>
+        <item>The client remote username (<url href="http://www.ietf.org/rfc/rfc931.txt">RFC 931</url>).</item>
       <tag><em>authuser</em></tag>
-      <item>The username with which the user authenticated himself.</item>
+      <item>The username used for authentication.</item>
       <tag><em>[date]</em></tag>
-        <item>Date and time of the request (RFC 1123).</item>
+        <item>Date and time of the request (<url href="http://www.ietf.org/rfc/rfc1123.txt">RFC 1123</url>).</item>
       <tag><em>"request"</em></tag>
-        <item>The request line exactly as it came from the client (RFC 1945).</item>
+        <item>The request line exactly as it came from the client (<url href="http://www.ietf.org/rfc/rfc1945.txt">RFC 1945</url>).</item>
         <tag><em>status</em></tag>
-        <item>The HTTP status code returned to the client (RFC 1945).</item>
+        <item>The HTTP status code returned to the client  (<url href="http://www.ietf.org/rfc/rfc1945.txt">RFC 1945</url>).</item>
         <tag><em>bytes</em></tag>
         <item>The content-length of the document transferred. </item>
       </taglist>
       <p>Internal server errors are recorded in the error log file. The
-        format of this file is a more ad hoc format than the logs using
+        format of this file is a more unplanned format than the logs using
       Common Logfile Format, but conforms to the following syntax:
         </p>
       <p><em>[date]</em> access to <em>path</em> failed for
@@ -481,73 +475,79 @@ http://your.server.org/eval?httpd_example:print(atom_to_list(apply(erlang,halt,[
   </section>
   
   <section>
-      <title>The Erlang Web Server API</title>
-      <p>The process of handling a HTTP request involves several steps
+      <title>Erlang Web Server API</title>
+      <p>The process of handling an HTTP request involves several steps,
         such as:</p>
       <list type="bulleted">
-        <item>Seting up connections, sending and receiving data.</item>
-        <item>URI to filename translation</item>
-        <item>Authenication/access checks.</item>
-        <item>Retriving/generating the response.</item>
-        <item>Logging</item>
+        <item>Setting up connections, sending and receiving data.</item>
+        <item>URI to filename translation.</item>
+        <item>Authentication/access checks.</item>
+        <item>Retrieving/generating the response.</item>
+        <item>Logging.</item>
       </list>
-      <p>To provide customization and extensibility of the HTTP servers
-        request handling most of these steps are handled by one or more
-        modules that may be replaced or removed at runtime, and of course
-        new ones can be added. For each request all modules will be
-        traversed in the order specified by the modules directive in the
-        server configuration file. Some parts mainly the communication
-        related steps are considered server core functionality and are
-        not implemented using the Erlang Web Server API.  A description of
-        functionality implemented by the Erlang Webserver API is described
-        in the section Inets Webserver Modules.</p>
+      <p>To provide customization and extensibility of the request 
+         handling of the HTTP servers, most of these steps are handled by 
+	 one or more modules. These modules can be replaced or removed at 
+	 runtime and new ones can be added. For each request, all modules are
+         traversed in the order specified by the module directive in the
+         server configuration file. Some parts, mainly the communication-
+         related steps, are considered server core functionality and are
+         not implemented using the Erlang web server API. A description of
+         functionality implemented by the Erlang webserver API is described
+         in <seealso marker="#Inets_Web_Server_Modules">Section 
+	 Inets Web Server Modules</seealso>.</p>
+
       <p>A module can use data generated by previous modules in the
-        Erlang Webserver API module sequence or generate data to be used
-        by consecutive Erlang Web Server API modules. This is made
-        possible due to an internal list of key-value tuples, also referred to
-        as interaction data. </p>
+        Erlang webserver API module sequence or generate data to be used
+        by consecutive Erlang Web Server API modules. This is
+        possible owing to an internal list of key-value tuples, referred to
+        as interaction data.</p>
       <note>
         <p>Interaction data enforces module dependencies and
-          should be avoided if possible. This means the order
-          of modules in the Modules property is significant.</p>
+          is to be avoided if possible. This means that the order
+          of modules in the modules property is significant.</p>
       </note>
 
       <section>
         <title>API Description</title>
-        <p>Each module implements server functionality
-          using the Erlang Web Server API should implement the following
+        <p>Each module that implements server functionality
+          using the Erlang web server API is to implement the following
           call back functions:</p>
         <list type="bulleted">
-          <item>do/1 (mandatory) - the function called when
-           a request should be handled.</item>
-          <item>load/2</item>
-          <item>store/2</item>
-          <item>remove/1</item>
+          <item><c>do/1</c> (mandatory) - the function called when
+           a request is to be handled</item>
+          <item><c>load/2</c></item>
+          <item><c>store/2</c></item>
+          <item><c>remove/1</c></item>
         </list>
         <p>The latter functions are needed only when new config
-          directives are to be introduced. For details see
-          <seealso marker="httpd">httpd(3)</seealso></p>
+          directives are to be introduced. For details, see
+          <seealso marker="httpd">httpd(3)</seealso>.</p>
       </section>
     </section>
 
   <section>
-    <title>Inets Web Server Modules</title> <p>The convention is that
-      all modules implementing some webserver functionality has the
-      name mod_*. When configuring the web server an appropriate
-      selection of these modules should be present in the Module
-      directive. Please note that there are some interaction dependencies
-      to take into account so the order of the modules can not be
-      totally random.</p>
+    <title>Inets Web Server Modules</title>
+    <marker id="Inets_Web_Server_Modules"></marker>
+    <p>The convention is that
+      all modules implementing some web server functionality has the
+      name <c>mod_*</c>. When configuring the web server, an appropriate
+      selection of these modules is to be present in the module
+      directive. Notice that there are some interaction dependencies
+      to take into account, so the order of the modules cannot be
+      random.</p>
 
     <section>
-      <title>mod_action - Filetype/Method-Based Script Execution.</title>
-      <p>Runs CGI scripts whenever a file of a
-	certain type or HTTP method (See RFC 1945) is requested.
+      <title>mod_action - Filetype/Method-Based Script Execution</title>
+      <p>This module runs CGI scripts whenever a file of a
+	certain type or HTTP method (see 
+	<url href="http://tools.ietf.org/html/rfc1945">RFC 1945</url>RFC 1945)
+	is requested.
       </p>
       <p>Uses the following Erlang Web Server API interaction data:
       </p>
       <list type="bulleted">
-	<item>real_name - from mod_alias</item>
+	<item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso>.</item>
       </list>
       <p>Exports the following Erlang Web Server API interaction data, if possible:
       </p>
@@ -559,48 +559,51 @@ http://your.server.org/eval?httpd_example:print(atom_to_list(apply(erlang,halt,[
 
     <section>
       <title>mod_alias - URL Aliasing</title>
-      <p>This module makes it possible to map different parts of the
-	host file system into the document tree e.i. creates aliases and
+      <p>The <seealso marker="mod_alias">mod_alias</seealso>
+      module makes it possible to map different parts of the
+	host file system into the document tree, that is, creates aliases and
 	redirections.</p>
         <p>Exports the following Erlang Web Server API interaction data, if possible:
       </p>
       <taglist>
 	<tag><c>{real_name, PathData}</c></tag>
-	<item>PathData is the argument used for API function mod_alias:path/3.</item>
+	<item><c>PathData</c> is the argument used for API function 
+	<seealso marker="mod_alias:path/3">mod_alias:path/3</seealso>.</item>
       </taglist>
     </section>
     
     <section>
-      <title>mod_auth - User Authentication </title>
-        <p>This module provides for basic user authentication using
-	textual files, dets databases as well as mnesia databases.</p>
+      <title>mod_auth - User Authentication</title>
+        <p>The <seealso marker="mod_auth">mod_auth(3)</seealso> 
+	module provides for basic user authentication using
+	textual files, <c>Dets</c> databases as well as <c>Mnesia</c> databases.</p>
       <p>Uses the following Erlang Web Server API interaction data:
       </p>
       <list type="bulleted">
-	<item>real_name - from mod_alias</item>
+	<item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item>
         </list>
       <p>Exports the following Erlang Web Server API interaction data:
       </p>
       <taglist>
 	<tag><c>{remote_user, User}</c></tag>
-          <item>The user name with which the user has authenticated himself.</item>
+          <item>The username used for authentication.</item>
       </taglist>
       
       
       <section>
-	<title>Mnesia as Authentication Database</title>
+	<title>Mnesia As Authentication Database</title>
 	
-	<p> If Mnesia is used as storage method, Mnesia must be
-	  started prio to the HTTP server. The first time Mnesia is
-	  started the schema and the tables must be created before
-	  Mnesia is started. A naive example of a module with two
-	  functions that creates and start mnesia is provided
-	  here. The function shall be used the first
-	  time. first_start/0 creates the schema and the tables. The
-	  second function start/0 shall be used in consecutive
-	  startups. start/0 Starts Mnesia and wait for the tables to
+	<p>If <c>Mnesia</c> is used as storage method, <c>Mnesia</c> must be
+	  started before the HTTP server. The first time <c>Mnesia</c> is
+	  started, the schema and the tables must be created before
+	  <c>Mnesia</c> is started. A simple example of a module with two
+	  functions that creates and start <c>Mnesia</c> is provided
+	  here. Function <c>first_start/0</c> is to be used the first
+	  time. It creates the schema and the tables.
+	  <c>start/0</c> is to be used in consecutive startups. 
+	  <c>start/0</c> starts <c>Mnesia</c> and waits for the tables to
 	  be initiated. This function must only be used when the
-	  schema and the tables already is created. </p>
+	  schema and the tables are already created.</p>
 	
 	<code>
 -module(mnesia_test).
@@ -624,28 +627,28 @@ first_start() ->
 
 start() ->
     mnesia:start(),
-    mnesia:wait_for_tables([httpd_user, httpd_group], 60000).                 
-	</code>
+    mnesia:wait_for_tables([httpd_user, httpd_group], 60000).  </code>
 	
-	<p>To create the Mnesia tables we use two records defined in
-	  mod_auth.hrl so the file must be included.  The first
-	  function first_start/0 creates a schema that specify on
-	  which nodes the database shall reside. Then it starts Mnesia
-	  and creates the tables. The first argument is the name of
-	  the tables, the second argument is a list of options how the
-	  table will be created, see Mnesia documentation for more
-	  information. Since the current implementation of the
-	  mod_auth_mnesia saves one row for each user the type must be
-	  bag.  When the schema and the tables is created the second
-	  function start/0 shall be used to start Mensia. It starts
-	  Mnesia and wait for the tables to be loaded. Mnesia use the
-	  directory specified as mnesia_dir at startup if specified,
-	  otherwise Mnesia use the current directory.  For security
-	  reasons, make sure that the Mnesia tables are stored outside
-	  the document tree of the HTTP server. If it is placed in the
-	  directory which it protects, clients will be able to
-	  download the tables.  Only the dets and mnesia storage
-	  methods allow writing of dynamic user data to disk. plain is
+	<p>To create the <c>Mnesia</c> tables, we use two records defined in
+	  <c>mod_auth.hrl</c>, so that file must be included. <c>first_start/0</c> 
+	  creates a schema that specifies on which nodes the database is to reside. 
+	  Then it starts <c>Mnesia</c> and creates the tables. The first argument 
+	  is the name of the tables, the second argument is a list of options of 
+	  how to create the table, see 
+	  <seealso marker="mnesia:mnesia"><c>mnesia</c></seealso>, documentation for 
+	  more information. As the implementation of the <c>mod_auth_mnesia</c> 
+	  saves one row for each user, the type must be <c>bag</c>.
+	  When the schema and the tables are created, function
+	  <seealso marker="mnesia:mnesia#start-0">mnesia:start/0</seealso>
+	  is used to start <c>Mnesia</c>  and 
+	  waits for the tables to be loaded. <c>Mnesia</c> uses the
+	  directory specified as <c>mnesia_dir</c> at startup if specified,
+	  otherwise <c>Mnesia</c> uses the current directory. For security
+	  reasons, ensure that the <c>Mnesia</c> tables are stored outside
+	  the document tree of the HTTP server. If they are placed in the
+	  directory which it protects, clients can download the tables. 
+	  Only the <c>Dets</c> and <c>Mnesia</c> storage
+	  methods allow writing of dynamic user data to disk. <c>plain</c> is
 	  a read only method.</p>
       </section>
 
@@ -653,19 +656,19 @@ start() ->
     
     <section>
       <title>mod_cgi - CGI Scripts</title>
-        <p>This module handles invoking of CGI scripts</p>
+        <p>This module handles invoking of CGI scripts.</p>
     </section>
     
     <section>
       <title>mod_dir - Directories</title>
       <p>This module generates an HTML directory listing
 	(Apache-style) if a client sends a request for a directory
-	instead of a file. This module needs to be removed from the
+	instead of a file. This module must be removed from the
 	Modules config directive if directory listings is unwanted.</p>
       <p>Uses the following Erlang Web Server API interaction data:
       </p>
       <list type="bulleted">
-	<item>real_name - from mod_alias</item>
+	<item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item>
       </list>
       <p>Exports the following Erlang Web Server API interaction data:
       </p>
@@ -677,27 +680,27 @@ start() ->
       </section>
 
     <section>
-      <title>mod_disk_log - Logging Using disk_log.</title>
+      <title>mod_disk_log - Logging Using Disk_Log.</title>
         <p>Standard logging using the "Common Logfile Format" and
-	disk_log(3).</p>
+	<seealso marker="kernel:disk_log">kernel:disk_log(3)</seealso>.</p>
         <p>Uses the following Erlang Web Server API interaction data:
       </p>
         <list type="bulleted">
-	<item>remote_user - from mod_auth</item>
+	<item><c>remote_user</c> - from <c>mod_auth</c></item>
       </list>
     </section>
 
     <section>
       <title>mod_esi - Erlang Server Interface</title>
-      <p>This module implements
-          the Erlang Server Interface (ESI) that provides a tight and
-	efficient interface to the execution of Erlang functions. </p>
-        <p>Uses the following Erlang Web Server API interaction data:
+      <p>The <seealso marker="mod_esi">mod_esi(3)</seealso>
+      module implements the Erlang Server Interface (ESI) providing a 
+      tight and efficient interface to the execution of Erlang functions.</p>
+      <p>Uses the following Erlang web server API interaction data:
       </p>
       <list type="bulleted">
-	<item>remote_user - from mod_auth</item>
+	<item><c>remote_user</c> - from <c>mod_auth</c></item>
       </list>
-      <p>Exports the following Erlang Web Server API interaction data:
+      <p>Exports the following Erlang web server API interaction data:
           </p>
       <taglist>
 	<tag><c>{mime_type, MimeType}</c></tag>
@@ -709,11 +712,11 @@ start() ->
       <section>
       <title>mod_get - Regular GET Requests</title>
       <p>This module is responsible for handling GET requests to regular 
-	files. GET requests for parts of files is handled by mod_range.</p>
-        <p>Uses the following Erlang Web Server API interaction data:
+	files. GET requests for parts of files is handled by <c>mod_range</c>.</p>
+        <p>Uses the following Erlang web server API interaction data:
       </p>
       <list type="bulleted">
-          <item>real_name - from mod_alias</item>
+          <item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item>
       </list>
       </section>
     
@@ -725,7 +728,7 @@ start() ->
         <p>Uses the following Erlang Web Server API interaction data:
       </p>
       <list type="bulleted">
-	<item>real_name - from mod_alias</item>
+	<item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item>
         </list>
     </section>
     
@@ -736,13 +739,13 @@ start() ->
       <p>Uses the following Erlang Web Server API interaction data:
       </p>
       <list type="bulleted">
-          <item>real_name - from mod_alias</item>
+          <item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item>
       </list>
       <p>Exports the following Erlang Web Server API interaction data:
       </p>
       <taglist>
 	<tag><c>{remote_user_name, User}</c></tag>
-	<item>The user name with which the user has authenticated himself.</item>
+	<item>The username used for authentication.</item>
         </taglist>
     </section>
     
@@ -750,84 +753,83 @@ start() ->
       <title>mod_log - Logging Using Text Files.</title>
       <p>Standard logging using the "Common Logfile Format" and text
 	files.</p>
-        <p>Uses the following Erlang Webserver API interaction data:
+        <p>Uses the following Erlang Web Server API interaction data:
       </p>
       <list type="bulleted">
-	<item>remote_user - from mod_auth</item>
+	<item><c>remote_user</c> - from <c>mod_auth</c></item>
         </list>
     </section>
     
       <section>
       <title>mod_range - Requests with Range Headers</title>
-      <p>This module response to requests for one or many ranges of a
-	file.  This is especially useful when downloading large files,
-	since a broken download may be resumed.</p>
-      <p>Note that request for multiple parts of a document will report a
+      <p>This module responses to requests for one or many ranges of a
+	file. This is especially useful when downloading large files,
+	as a broken download can be resumed.</p>
+      <p>Notice that request for multiple parts of a document report a
 	size of zero to the log file.</p>
-        <p>Uses the following Erlang Webserver API interaction data:
+        <p>Uses the following Erlang Web Server API interaction data:
       </p>
       <list type="bulleted">
-	<item>real_name - from mod_alias</item>
+	<item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item>
       </list>
     </section>
 
     <section>
       <title>mod_response_control - Requests with If* Headers</title>
-      <p>This module controls that the conditions in the requests is
-	fulfilled. For example a request may specify that the answer
-	only is of interest if the content is unchanged since last
-	retrieval. Or if the content is changed the range-request shall
-	be converted to a request for the whole file instead.</p> <p>If
-	a client sends more then one of the header fields that restricts
-	the servers right to respond, the standard does not specify how
-	this shall be handled.  httpd will control each field in the
-	following order and if one of the fields not match the current
-	state the request will be rejected with a proper response.
-	<br></br>
+      <p>This module controls that the conditions in the requests are
+	fulfilled. For example, a request can specify that the answer
+	only is of interest if the content is unchanged since the last
+	retrieval. If the content is changed, the range request is to
+	be converted to a request for the whole file instead.</p> 
+	<p>If a client sends more than one of the header fields that 
+	restricts the servers right to respond, the standard does not 
+	specify how this is to be handled.
+	<seealso marker="httpd">httpd(3)</seealso> controls each 
+	field in the following order and if one of the fields does not 
+	match the current state, the request is rejected with a proper 
+	response:</p>
+	<p><c>If-modified</c></p>
+	<p><c>If-Unmodified</c></p>
+	<p><c>If-Match</c></p>
+	<p><c>If-Nomatch</c></p>
 	
-          1.If-modified          <br></br>
-
-          2.If-Unmodified          <br></br>
-
-          3.If-Match          <br></br>
-
-          4.If-Nomatch          <br></br>
-</p>
-      <p>Uses the following Erlang Webserver API interaction data:
+      <p>Uses the following Erlang Web Server API interaction data:
       </p>
       <list type="bulleted">
-	<item>real_name - from mod_alias</item>
+	<item><c>real_name</c> - from  <seealso marker="mod_alias">mod_alias</seealso></item>
       </list>
-      <p>Exports the following Erlang Webserver API interaction data:
+      <p>Exports the following Erlang Web Server API interaction data:
       </p>
       <taglist>
 	<tag><c>{if_range, send_file}</c></tag>
-	<item>The conditions for the range request was not fulfilled.
+	<item>The conditions for the range request are not fulfilled.
 	  The response must not be treated as a range request, instead it
-	  must be treated as a ordinary get request. </item>
+	  must be treated as an ordinary get request.</item>
         </taglist>
     </section>
     
     <section>
       <title>mod_security - Security Filter</title>
-        <p>This module serves as a filter for authenticated requests
-	handled in mod_auth.  It provides possibility to restrict users
-	from access for a specified amount of time if they fail to
+        <p>The <seealso marker="mod_security">mod_security</seealso> 
+	module serves as a filter for authenticated requests
+	handled in <seealso marker="mod_auth">mod_auth(3)</seealso>. 
+	It provides a possibility to restrict users from 
+	access for a specified amount of time if they fail to
 	authenticate several times. It logs failed authentication as
-	well as blocking of users, and it also calls a configurable
-	call-back module when the events occur.  </p>
+	well as blocking of users, and it calls a configurable
+	callback module when the events occur.</p>
       <p>There is also an
-	API to manually block, unblock and list blocked users or users,
-	who have been authenticated within a configurable amount of
-	time.</p>
+	API to block or unblock users manually. This API can also list 
+	blocked users or users who have been authenticated within a 
+	configurable amount of time.</p>
     </section>
     
     <section>
       <title>mod_trace - TRACE Request</title>
-      <p>mod_trace is responsible for handling of TRACE requests.
+      <p><c>mod_trace</c> is responsible for handling of TRACE requests.
 	Trace is a new request method in HTTP/1.1. The intended use of
 	trace requests is for testing. The body of the trace response is
-	the request message that the responding Web server or proxy
+	the request message that the responding web server or proxy
 	received.</p>
     </section>
   </section>
diff --git a/lib/inets/doc/src/http_uri.xml b/lib/inets/doc/src/http_uri.xml
index 4b59c0c7a2..47c40da96a 100644
--- a/lib/inets/doc/src/http_uri.xml
+++ b/lib/inets/doc/src/http_uri.xml
@@ -35,64 +35,86 @@
 
   <description>
     <p>This module provides utility functions for working with URIs, 
-    according to RFC 3986. </p>
-
+    according to 
+    <url href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986</url>.</p>
   </description>
   
   <section>
-    <title>COMMON DATA TYPES </title>
+    <title>DATA TYPES</title>
     <p>Type definitions that are used more than once in
       this module:</p>
-    <code type="none"><![CDATA[
-boolean() = true | false 
-string()  = list of ASCII characters 
-    ]]></code>
+    <p><c>boolean() = true | false</c></p>
+    <p><c>string()</c> = list of ASCII characters</p>
 
   </section>
   
   <section>
-    <title>URI DATA TYPES </title>
+    <title>URI DATA TYPES</title>
     <p>Type definitions that are related to URI:</p>
-    <p>For more information about URI, see RFC 3986. </p>
-
-    <code type="none"><![CDATA[
-uri()       = string() - Syntax according to the URI definition in rfc 3986,
-                         e.g.: "http://www.erlang.org/"
-user_info() = string()
-scheme()    = atom()   - Example: http, https
-host()      = string()
-port()      = pos_integer()
-path()      = string() - Representing a file path or directory path 
-query()     = string()
-fragment()  = string()
-    ]]></code>
-
+    
+<taglist>
+       <tag><c>uri() = string()</c></tag>
+       <item><p>Syntax according to the URI definition in RFC 3986,
+       for example, "http://www.erlang.org/"</p></item>
+       <tag><c>user_info() = string()</c></tag>
+       <item><p></p></item>
+       <tag><c>scheme() = atom()</c></tag>
+       <item><p>Example: http, https</p></item>
+       <tag><c>host() = string()</c></tag>
+       <item><p></p></item>
+       <tag><c>port() = pos_integer()</c></tag>
+       <item><p></p></item>
+       <tag><c>path() = string()</c></tag>
+       <item><p>Represents a file path or directory path</p></item>
+       <tag><c>query() = string()</c></tag>
+       <item><p></p></item>
+       <tag><c>fragment() = string()</c></tag>
+       <item><p></p></item>
+     </taglist>
+   
+     <p>For more information about URI, see
+     <url href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986</url>.</p>
     <marker id="scheme_defaults"></marker>
   </section>
   
   <funcs>
     <func>
-      <name>scheme_defaults() -> SchemeDefaults</name>
-      <fsummary>A list of scheme and their default ports</fsummary>
+      <name>decode(HexEncodedURI) -> URI</name>
+      
+      <fsummary>Decodes a hexadecimal encoded URI.</fsummary>
       <type>
-        <v>SchemeDefaults = [{scheme(), default_scheme_port_number()}] </v> 
-	<v>default_scheme_port_number() = pos_integer()</v>
+        <v>HexEncodedURI = string() - A possibly hexadecimal encoded URI</v>
+        <v>URI = uri()</v>
       </type>
+
       <desc>
-        <p>This function provides a list of the scheme and their default 
-	port numbers currently supported (by default) by this utility. </p>
+        <p>Decodes a possibly hexadecimal encoded URI.</p>
 
-        <marker id="parse"></marker>
+      </desc>
+    </func>
+    <func>
+      <name>encode(URI) -> HexEncodedURI</name>
+      
+      <fsummary>Encodes a hexadecimal encoded URI.</fsummary>
+      <type>
+        <v>URI = uri()</v>
+        <v>HexEncodedURI = string() - Hexadecimal encoded URI</v>
+      </type>
+
+      <desc>
+        <p>Encodes a hexadecimal encoded URI.</p>
+
+        <marker id="decode"></marker>
       </desc>
     </func>
 
     <func>
       <name>parse(URI) -> {ok, Result} | {error, Reason}</name>
       <name>parse(URI, Options) -> {ok, Result} | {error, Reason}</name>
-      <fsummary>Parse an URI</fsummary>
+      <fsummary>Parses a URI.</fsummary>
       <type>
-        <v>URI = uri() </v> 
-        <v>Options = [Option] </v> 
+        <v>URI = uri()</v> 
+        <v>Options = [Option]</v> 
         <v>Option = {ipv6_host_with_brackets, boolean()} | 
                     {scheme_defaults, scheme_defaults()} |
                     {fragment, boolean()}]</v>
@@ -104,62 +126,49 @@ fragment()  = string()
 	<v>Path = path()</v>
 	<v>Query = query()</v>
         <v>Fragment = fragment()</v>
-	<v>Reason = term() </v>
+	<v>Reason = term()</v>
       </type>
       <desc>
-        <p>This function is used to parse an URI. If no scheme defaults 
-	are provided, the value of 
+        <p>Parses a URI. If no scheme defaults 
+	are provided, the value of the
 	<seealso marker="#scheme_defaults">scheme_defaults</seealso>
-	function will be used. </p>
+	function is used.</p>
 
-        <p>Note that when parsing an URI with an unknown scheme (that is, 
-	a scheme not found in the scheme defaults) a port number must be 
-	provided or else the parsing will fail. </p>
+        <p>When parsing a URI with an unknown scheme (that is, 
+	a scheme not found in the scheme defaults), a port number must be 
+	provided, otherwise the parsing fails.</p>
 
-        <p>If the fragment option is true, the URI fragment will be returned as
-          part of the parsing result, otherwise it is completely ignored.</p>
+        <p>If the fragment option is <c>true</c>, the URI fragment is returned as
+          part of the parsing result, otherwise it is ignored.</p>
 
         <marker id="encode"></marker>
       </desc>
     </func>
 
     <func>
-      <name>encode(URI) -> HexEncodedURI</name>
-      
-      <fsummary>Hex encode an URI</fsummary>
+      <name>scheme_defaults() -> SchemeDefaults</name>
+      <fsummary>A list of the scheme and their default ports.</fsummary>
       <type>
-        <v>URI = uri()</v>
-        <v>HexEncodedURI = string() - Hex encoded uri</v>
+        <v>SchemeDefaults = [{scheme(), default_scheme_port_number()}] </v> 
+	<v>default_scheme_port_number() = pos_integer()</v>
       </type>
-
       <desc>
-        <p>Hex encode an URI. </p>
+        <p>Provides a list of the scheme and their default 
+	port numbers supported (by default) by this utility.</p>
 
-        <marker id="decode"></marker>
+        <marker id="parse"></marker>
       </desc>
     </func>
 
-    <func>
-      <name>decode(HexEncodedURI) -> URI</name>
-      
-      <fsummary>Decode a hex encoded URI</fsummary>
-      <type>
-        <v>HexEncodedURI = string() - A possibly hex encoded uri</v>
-        <v>URI = uri()</v>
-      </type>
-
-      <desc>
-        <p>Decode a possibly hex encoded URI. </p>
-
-      </desc>
-    </func>
+   
 
   </funcs>
 
 <!--
   <section>
     <title>SEE ALSO</title>
-    <p>RFC 2616, <seealso marker="inets">inets(3)</seealso>,
+    <p><url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>, 
+    <seealso marker="inets">inets(3)</seealso>,
       <seealso marker="kernel:gen_tcp">gen_tcp(3)</seealso>, 
       <seealso marker="ssl:ssl">ssl(3)</seealso>
     </p>
diff --git a/lib/inets/doc/src/httpc.xml b/lib/inets/doc/src/httpc.xml
index 05eec9cfd3..31e44f405c 100644
--- a/lib/inets/doc/src/httpc.xml
+++ b/lib/inets/doc/src/httpc.xml
@@ -31,143 +31,252 @@
   </header>
 
   <module>httpc</module>
-  <modulesummary>An HTTP/1.1 client </modulesummary>
+  <modulesummary>An HTTP/1.1 client</modulesummary>
 
   <description>
-    <p>This module provides the API to a HTTP/1.1 compatible client according 
-      to RFC 2616, caching is currently not supported.</p>
+    <p>This module provides the API to an HTTP/1.1 compatible client according 
+      to <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>. 
+    Caching is not supported.</p>
     <note>
-      <p>When starting the Inets application a manager process for the
-	default profile will be started. The functions in this API
-	that do not explicitly use a profile will access the
+      <p>When starting the <c>Inets</c> application, a manager process for the
+	default profile is started. The functions in this API
+	that do not explicitly use a profile accesses the
 	default profile. A profile keeps track of proxy options,
-	cookies and other options that can be applied to more than one
-	request. </p>
+	cookies, and other options that can be applied to more than one
+	request.</p>
 
-	<p>If the scheme https is used the ssl application needs to be
-	started. When https links needs to go through a proxy the
+	<p>If the scheme <c>https</c> is used, the <c>SSL</c> application must
+	be started. When <c>https</c> links need to go through a proxy, the
 	CONNECT method extension to HTTP-1.1 is used to establish a
-	tunnel and then the connection is upgraded to TLS,
-	however "TLS upgrade" according to RFC 2817 is not
+	tunnel and then the connection is upgraded to TLS.
+	However, "TLS upgrade" according to <url href="http://www.ietf.org/rfc/rfc2817.txt">RFC 2817</url>is not
 	supported.</p>
 
-      <p>Also note that pipelining will only be used if the pipeline
-      timeout is set, otherwise persistent connections without
-      pipelining will be used e.i. the  client always waits for
+      <p>Pipelining is only used if the pipeline
+      time-out is set, otherwise persistent connections without
+      pipelining are used. That is, the client always waits for
       the previous response before sending the next request.</p>
     </note>
-    <p>There are some usage examples in the <seealso
-    marker="http_client">Inets User's Guide.</seealso></p>
+    <p>Some examples are provided in the <seealso
+    marker="http_client">Inets User's Guide</seealso>.</p>
   </description>
   
   <section>
-    <title>COMMON DATA TYPES </title>
+    <title>DATA TYPES</title>
+    <marker id="DATA_TYPES"></marker>
     <p>Type definitions that are used more than once in
       this module:</p>
-    <code type="none"><![CDATA[
-boolean()    = true | false 
-string()     = list of ASCII characters 
-request_id() = ref() 
-profile()    = atom()
-path()       = string() representing a file path or directory path 
-ip_address() = See inet(3)
-socket_opt() = See the Options used by gen_tcp(3) and 
-               ssl(3) connect(s)
-    ]]></code>
-
+    <p><c>boolean() = true | false</c></p>
+    <p><c>string()</c> = list of ASCII characters</p>
+    <p><c>request_id() = ref()</c></p>
+    <p><c>profile() = atom()</c></p>
+    <p><c>path() = string()</c> representing a file path or directory path</p>
+    <p><c>ip_address()</c> = See the
+    <seealso marker="kernel:inet">inet(3)</seealso> manual page in <c>Kernel</c>.</p>
+    <p><c>socket_opt()</c> = See the options used by
+    <seealso marker="kernel:gen_tcp">gen_tcp(3)</seealso> <c>gen_tcp(3)</c> and 
+    <seealso marker="ssl:ssl">ssl(3)</seealso> connect(s)</p>
+  
   </section>
   
   <section>
-    <title>HTTP DATA TYPES </title>
-    <p>Type definitions that are related to HTTP:</p>
-    <p>For more information about HTTP see rfc 2616</p>
-
-    <code type="none"><![CDATA[
-method()         = head | get | put | post | trace | options | delete
-request()        = {url(), headers()} | 
-                   {url(), headers(), content_type(), body()}
-url()            = string() - Syntax according to the URI definition in rfc 2396, ex: "http://www.erlang.org"
-status_line()    = {http_version(), status_code(), reason_phrase()}
-http_version()   = string() ex: "HTTP/1.1"
-status_code()    = integer()
-reason_phrase()  = string()
-content_type()   = string()
-headers()        = [header()]
-header()         = {field(), value()}
-field()          = string() 
-value()          = string() 
-body()           = string() | 
-                   binary() |
-                   {fun(accumulator()) -> body_processing_result(), 
-                    accumulator()} |
-                   {chunkify, 
-                    fun(accumulator()) -> body_processing_result(), 
-                    accumulator()}
-body_processing_result() = eof | {ok, iolist(), accumulator()}
-accumulator()    = term()
-filename()       = string() 
-    ]]></code>
+    <title>HTTP DATA TYPES</title>
+    <p>Type definitions related to HTTP:</p>
 
-  </section>
+    <p><c>method() = head | get | put | post | trace | options | delete</c></p>
+    <taglist>
+      <tag><c>request()</c></tag>
+      <item><p>= <c>{url(), headers()}</c></p>
+      <p>| <c>{url(), headers(), content_type(), body()}</c></p>
+      </item>
+    </taglist>
+    <p><c>url() = string()</c> syntax according to the URI definition in
+    <url href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</url>, 
+    for example <c>"http://www.erlang.org"</c></p>
+    <p><c>status_line() = {http_version(), status_code(), reason_phrase()}</c></p>
+    <p><c>http_version() = string()</c>, for example, <c>"HTTP/1.1"</c></p>
+    <p><c>status_code() = integer()</c></p>
+    <p><c>reason_phrase() = string()</c></p>
+    <p><c>content_type() = string()</c></p>
+    <p><c>headers() = [header()]</c></p>
+    <p><c>header() = {field(), value()}</c></p>
+    <p><c>field() = string()</c></p>
+    <p><c>value() = string()</c></p>
+    <taglist>
+      <tag><c>body()</c></tag>
+      <item><p>= <c>string() | binary()</c></p>
+      <p>| <c>{fun(accumulator())</c></p>
+      <p><c> -> body_processing_result(), accumulator()}</c></p>
+      <p>| <c>{chunkify, fun(accumulator())</c></p>
+      <p><c> -> body_processing_result(), accumulator()}</c></p>
+      </item>
+    </taglist>
+    <p><c>body_processing_result() = eof | {ok, iolist(), accumulator()}</c></p>
+    <p><c>accumulator() = term()</c></p>
+    <p><c>filename() = string()</c></p>
+ <p>For more information about HTTP, see
+ <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>.</p> 
+</section>
   
   <section>
-    <title>SSL DATA TYPES </title>
+    <title>SSL DATA TYPES</title>
     <p>See <seealso marker="ssl:ssl">ssl(3)</seealso> for information
-    about ssl options (<c>ssloptions()</c>). </p>
+    about <c>SSL</c> options (<c>ssloptions()</c>). </p>
   </section>
 
   <section>
-    <title>HTTP CLIENT SERVICE START/STOP </title>
+    <title>HTTP CLIENT SERVICE START/STOP</title>
     
-    <p>A HTTP client can be configured to start when starting the inets
+    <p>An HTTP client can be configured to start when starting the <c>Inets</c>
       application or started dynamically in runtime by calling the
-      inets application API <c>inets:start(httpc, ServiceConfig)</c>, or
-      <c>inets:start(httpc,  ServiceConfig, How)</c>
-      see <seealso marker="inets">inets(3)</seealso>. Below follows a
-      description of the available configuration options.</p>
+      <c>Inets</c> application API <c>inets:start(httpc, ServiceConfig)</c>
+      or <c>inets:start(httpc,  ServiceConfig, How)</c>,
+      see <seealso marker="inets">inets(3)</seealso>.
+      The configuration options are as follows:</p>
     <taglist>
       <tag>{profile, profile()}</tag>
-      <item>Name of the profile, see
-	common data types below, this option is mandatory.</item>
+      <item><p>Name of the profile, see
+	<seealso marker="#DATA_TYPES">DATA TYPES</seealso>.
+      This option is mandatory.</p></item>
       <tag>{data_dir, path()}</tag>
-      <item>Directory where the profile
-	may save persistent data, if omitted all cookies will be treated
-	as session cookies.</item>
+      <item><p>Directory where the profile
+	can save persistent data. If omitted, all cookies are treated
+	as session cookies.</p></item>
     </taglist>
 
     <p>The client can be stopped using <c>inets:stop(httpc, Pid)</c> or
     <c>inets:stop(httpc, Profile)</c>.</p>
-    
-    <marker id="request1"></marker>
   </section>
   
   <funcs>
+   
+    <func>
+      <name>cancel_request(RequestId) -></name>
+      <name>cancel_request(RequestId, Profile) -> ok</name>
+      <fsummary>Cancels an asynchronous HTTP request.</fsummary>
+      <type>
+        <v>RequestId = request_id() - A unique identifier as returned
+        by request/4</v>
+	<v>Profile = profile() | pid()</v>
+	<d>When started <c>stand_alone</c> only the pid can be used.</d>
+      </type>
+      <desc>
+        <p>Cancels an asynchronous HTTP request. Notice that this does not guarantee
+	that the request response is not delivered. Because it is asynchronous,
+	the request can already have been completed when the cancellation arrives.
+	</p>
+      </desc>
+    </func>
+
+    <func>
+      <name>cookie_header(Url) -> </name>
+      <name>cookie_header(Url, Profile | Opts) -> header() | {error, Reason}</name>
+      <name>cookie_header(Url, Opts, Profile) -> header() | {error, Reason}</name>
+      <fsummary>Returns the cookie header that would have been sent when
+      making a request to URL using the profile <c>Profile</c>.</fsummary>
+      <type>
+        <v>Url = url()</v>
+        <v>Opts = [cookie_header_opt()]</v>
+	<v>Profile = profile() | pid()</v>
+	<d>When started <c>stand_alone</c>.</d>
+        <v>cookie_header_opt() = {ipv6_host_with_brackets, boolean()}</v>
+      </type>
+      <desc>
+        <p>Returns the cookie header that would have been sent
+	when making a request to <c>Url</c> using profile <c>Profile</c>.
+	If no profile is specified, the default profile is used.</p>
+	<p>Option <c>ipv6_host_with_bracket</c> deals with how to 
+	parse IPv6 addresses. For details,
+	see argument <c>Options</c> of
+	<seealso marker="#request-4">request/[4,5]</seealso>.</p>
+      </desc>
+    </func>
+
+     <func>
+      <name>get_options(OptionItems) -> {ok, Values} | {error, Reason}</name>
+      <name>get_options(OptionItems, Profile) -> {ok, Values} | {error, Reason}</name>
+      <fsummary>Gets the currently used options.</fsummary>
+      <type>
+        <v>OptionItems = all | [option_item()]</v>
+	<v>option_item() = proxy |
+	                   https_proxy |
+                           max_sessions | 
+			   keep_alive_timeout | 
+	                   max_keep_alive_length | 
+			   pipeline_timeout | 
+			   max_pipeline_length | 
+			   cookies | 
+			   ipfamily | 
+			   ip | 
+			   port | 
+			   socket_opts | 
+	                   verbose</v>
+	<v>Profile = profile() | pid()</v>
+	<d>When started <c>stand_alone</c> only the pid can used.</d>
+        <v>Values = [{option_item(), term()}]</v>
+        <v>Reason = term()</v>
+      </type>
+      <desc>
+        <p>Retrieves the options currently used by the client.</p>
+      </desc>
+    </func>
+
+    <func>
+      <name>info() -> list()</name>
+      <name>info(Profile) -> list()</name>
+      <fsummary>Produces a list of miscellaneous information.</fsummary>
+      <type>
+	<v>Profile = profile() | pid()</v>
+	<d>When started <c>stand_alone</c> only the pid can be used.</d>
+      </type>
+      <desc>
+        <p>Produces a list of miscellaneous information. 
+	Intended for debugging. 
+	If no profile is specified, the default profile is used.</p>
+      </desc>
+    </func>
+
+    
+    <func>
+      <name>reset_cookies() -> void()</name>
+      <name>reset_cookies(Profile) -> void()</name>
+      <fsummary>Resets the cookie database.</fsummary>
+      <type>
+	<v>Profile = profile() | pid()</v>
+	<d>When started <c>stand_alone</c> only the pid can be used.</d>
+      </type>
+      <desc>
+        <p>Resets (clears) the cookie database for the specified 
+	<c>Profile</c>. If no profile is specified the default profile 
+	is used.</p>
+      </desc>
+    </func>
+    
     <func>
       <name>request(Url) -> </name>
       <name>request(Url, Profile) -> {ok, Result} | {error, Reason}</name>
-      <fsummary>Sends a get HTTP-request</fsummary>
+      <fsummary>Sends a get HTTP request.</fsummary>
       <type>
-        <v>Url = url() </v> 
+        <v>Url = url()</v> 
 	<v>Result = {status_line(), headers(), Body} | 
-                    {status_code(), Body} | request_id() </v>
+                    {status_code(), Body} | request_id()</v>
 	<v>Body = string() | binary()</v>
-	<v>Profile = profile() | pid() (when started <c>stand_alone</c>)</v>
-	<v>Reason = term() </v>
+	<v>Profile = profile() | pid()</v>
+	<d>When started <c>stand_alone</c> only the pid can be used.</d>
+	<v>Reason = term()</v>
       </type>
       <desc>
         <p>Equivalent to <c>httpc:request(get, {Url, []}, [], [])</c>.</p>
-
-        <marker id="request2"></marker>
       </desc>
     </func>
 
     <func>
-      <name>request(Method, Request, HTTPOptions, Options) -> </name>
+      <name>request(Method, Request, HTTPOptions, Options) -></name>
       <name>request(Method, Request, HTTPOptions, Options, Profile) -> {ok, Result} | {ok, saved_to_file} | {error, Reason}</name>
       
-      <fsummary>Sends a HTTP-request</fsummary>
+      <fsummary>Sends an HTTP request.</fsummary>
       <type>
-        <v>Method = method() </v>
+        <v>Method = method()</v>
         <v>Request = request()</v>
         <v>HTTPOptions = http_options()</v>
         <v>http_options() = [http_option()]</v>
@@ -191,215 +300,200 @@ filename()       = string()
                       {socket_opts,             socket_opts()} | 
                       {receiver,                receiver()},
 	              {ipv6_host_with_brackets, boolean()}}</v>
-        <v>stream_to() = none | self | {self, once} | filename() </v>
+        <v>stream_to() = none | self | {self, once} | filename()</v>
         <v>socket_opts() = [socket_opt()]</v>
-        <v>receiver() = pid() | function()/1 | {Module, Function, Args} </v>
-        <v>Module = atom() </v>
-        <v>Function = atom() </v>
-        <v>Args = list() </v>
-	<v>body_format() = string | binary </v>
+        <v>receiver() = pid() | function()/1 | {Module, Function, Args}</v>
+        <v>Module = atom()</v>
+        <v>Function = atom()</v>
+        <v>Args = list()</v>
+	<v>body_format() = string | binary</v>
         <v>Result = {status_line(), headers(), Body} | 
-                    {status_code(), Body} | request_id() </v>
+                    {status_code(), Body} | request_id()</v>
         <v>Body = string() | binary()</v>
-        <v>Profile = profile() | pid() (when started <c>stand_alone</c>)</v>
+        <v>Profile = profile() | pid()</v>
+	<d>When started <c>stand_alone</c> only the pid can be used.</d>
         <v>Reason = {connect_failed, term()} | 
-                    {send_failed, term()} | term() </v>
+                    {send_failed, term()} | term()</v>
       </type>
 
       <desc>
-        <p>Sends a HTTP-request. The function can be both synchronous
-	and asynchronous. In the later case the function will return
-	<c>{ok, RequestId}</c> and later on the information will be delivered
-	to the <c>receiver</c> depending on that value. </p>
+        <p>Sends an HTTP request. The function can be both synchronous
+	and asynchronous. In the latter case, the function returns
+	<c>{ok, RequestId}</c> and then the information is delivered
+	to the <c>receiver</c> depending on that value.</p>
 
-        <p>Http option (<c>http_option()</c>) details: </p>
+        <p>HTTP option (<c>http_option()</c>) details:</p>
         <marker id="request2_http_options"></marker>
         <taglist>
           <tag><c><![CDATA[timeout]]></c></tag>
           <item>
-            <p>Timeout time for the request. </p>
-            <p>The clock starts ticking as soon as the request has been
-	    sent. </p>
-            <p>Time is in milliseconds. </p>
-            <p>Defaults to <c>infinity</c>. </p>
+            <p>Time-out time for the request.</p>
+            <p>The clock starts ticking when the request is sent.</p>
+            <p>Time is in milliseconds.</p>
+            <p>Default is <c>infinity</c>.</p>
 	  </item>
 
           <tag><c><![CDATA[connect_timeout]]></c></tag>
           <item>
-            <p>Connection timeout time, used during the initial request, 
-	    when the client is <em>connecting</em> to the server. </p>
-            <p>Time is in milliseconds. </p>
-            <p>Defaults to the value of the <c>timeout</c> option. </p>
+            <p>Connection time-out time, used during the initial request, 
+	    when the client is <em>connecting</em> to the server.</p>
+            <p>Time is in milliseconds.</p>
+            <p>Default is the value of option <c>timeout</c>.</p>
 	  </item>
 
           <tag><c><![CDATA[ssl]]></c></tag>
           <item>
-            <p>This is the default ssl config option, currently defaults to 
-	    <c>essl</c>, see below. </p>
-            <p>Defaults to <c>[]</c>. </p>
-	  </item>
-
-          <tag><c><![CDATA[essl]]></c></tag>
-          <item>
-            <p>If using the Erlang based implementation of SSL, 
-	    these SSL-specific options are used. </p>
-            <p>Defaults to <c>[]</c>. </p>
+            <p>This is the <c>SSL/TLS</c> connectin configuration option.</p>
+            <p>Defaults to <c>[]</c>. See <seealso marker="ssl:ssl">ssl:connect/[2, 3,4]</seealso>  for availble options.</p>
 	  </item>
 
           <tag><c><![CDATA[autoredirect]]></c></tag>
           <item>
-	    <p>Should the client automatically retrieve the information
-	    from the new URI and return that as the result instead 
-	    of a 30X-result code. </p>
-	    <p>Note that for some 30X-result codes automatic redirect 
-	    is not allowed. In these cases the 30X-result will always
-	    be returned. </p>
-	    <p>Defaults to <c>true</c>. </p>
+	    <p>The client automatically retrieves the information
+	    from the new URI and returns that as the result, instead 
+	    of a 30X-result code.</p>
+	    <p>For some 30X-result codes, automatic redirect 
+	    is not allowed. In these cases the 30X-result is always
+	    returned.</p>
+	    <p>Default is <c>true</c>.</p>
 	  </item>
 
           <tag><c><![CDATA[proxy_auth]]></c></tag>
           <item>
-            <p>A proxy-authorization header using the provided user name and 
-	    password will be added to the request. </p>
+            <p>A proxy-authorization header using the provided username and 
+	    password is added to the request.</p>
 	  </item>
 
           <tag><c><![CDATA[version]]></c></tag>
           <item>
             <p>Can be used to make the client act as an <c>HTTP/1.0</c> or
 	    <c>HTTP/0.9</c> client. By default this is an <c>HTTP/1.1</c> 
-	    client. When using <c>HTTP/1.0</c> persistent connections will 
-	    not be used. </p>
-	    <p>Defaults to the string <c>"HTTP/1.1"</c>. </p>
+	    client. When using <c>HTTP/1.0</c> persistent connections are 
+	    not used.</p>
+	    <p>Default is the string <c>"HTTP/1.1"</c>.</p>
 	  </item>
 
           <tag><c><![CDATA[relaxed]]></c></tag>
           <item>
-            <p>If set to <c>true</c> workarounds for known server deviations 
-	    from the HTTP-standard are enabled. </p>
-            <p>Defaults to <c>false</c>. </p>
+            <p>If set to <c>true</c>, workarounds for known server deviations 
+	    from the HTTP-standard are enabled.</p>
+            <p>Default is <c>false</c>.</p>
 	  </item>
 
 	  <tag><c><![CDATA[url_encode]]></c></tag>
           <item>
-            <p>Will apply Percent-encoding, also known as URL encoding on the 
+            <p>Applies Percent-encoding, also known as URL encoding on the 
 	    URL.</p>
-	    <p>Defaults to <c>false</c>. </p>
+	    <p>Default is <c>false</c>.</p>
 	  </item>
         </taglist>
 
-        <p>Option (<c>option()</c>) details: </p>
+        <p>Option (<c>option()</c>) details:</p>
         <taglist>
           <tag><c><![CDATA[sync]]></c></tag>
           <item>
-            <p>Shall the request be synchronous or asynchronous. </p>
-            <p>Defaults to <c>true</c>. </p>
+            <p>Option for the request to be synchronous or asynchronous.</p>
+            <p>Default is <c>true</c>.</p>
 	  </item>
 
           <tag><c><![CDATA[stream]]></c></tag>
           <item>
             <p>Streams the body of a 200 or 206 response to the calling 
 	    process or to a file. When streaming to the calling process 
-	    using the option <c>self</c> the following stream messages
-	    will be sent to that process: <c>{http, {RequestId,
+	    using option <c>self</c>, the following stream messages
+	    are sent to that process: <c>{http, {RequestId,
 	    stream_start, Headers}}, {http, {RequestId, stream,
-	    BinBodyPart}}, {http, {RequestId, stream_end, Headers}}</c>. When
-	    streaming to the calling processes using the option
-	    <c>{self, once}</c> the first message will have an additional
-	    element e.i. <c>{http, {RequestId, stream_start, Headers, Pid}}</c>,
-	    this is the process id that should be used as an argument to
+	    BinBodyPart}}, and {http, {RequestId, stream_end, Headers}}</c>.</p>
+	    <p>When streaming to the calling processes using option
+	    <c>{self, once}</c>, the first message has an extra
+	    element, that is, <c>{http, {RequestId, stream_start, Headers, Pid}}</c>.
+	    This is the process id to be used as an argument to
 	    <c>http:stream_next/1</c> to trigger the next message to be sent to
-	    the calling process. </p>
-	    <p>Note that it is possible that chunked encoding will add
+	    the calling process.</p>
+	    <p>Notice that chunked encoding can add
 	    headers so that there are more headers in the <c>stream_end</c>
-	    message than in the <c>stream_start</c>.
-	    When streaming to a file and the request is asynchronous the
-	    message <c>{http, {RequestId, saved_to_file}}</c> will be sent. </p>
-            <p>Defaults to <c>none</c>. </p>
+	    message than in <c>stream_start</c>.
+	    When streaming to a file and the request is asynchronous, the
+	    message <c>{http, {RequestId, saved_to_file}}</c> is sent.</p>
+            <p>Default is <c>none</c>.</p>
 	  </item>
 
           <tag><c><![CDATA[body_format]]></c></tag>
           <item>
-            <p>Defines if the body shall be delivered as a string or as a 
+            <p>Defines if the body is to be delivered as a string or 
 	    binary. This option is only valid for the synchronous 
-	    request. </p>
-            <p>Defaults to <c>string</c>. </p>
+	    request.</p>
+            <p>Default is <c>string</c>.</p>
 	  </item>
 
           <tag><c><![CDATA[full_result]]></c></tag>
           <item>
-            <p>Should a "full result" be returned to the caller (that is,
-	    the body, the headers and the entire status-line) or not 
-	    (the body and the status code). </p>
-            <p>Defaults to <c>true</c>. </p>
+            <p>Defines if a "full result" is to be returned to the caller (that is,
+	    the body, the headers, and the entire status line) or not 
+	    (the body and the status code).</p>
+            <p>Default is <c>true</c>.</p>
 	  </item>
 
           <tag><c><![CDATA[headers_as_is]]></c></tag>
           <item>
-            <p>Shall the headers provided by the user be made 
-	    lower case or be regarded as case sensitive. </p>
-            <p>Note that the http standard requires them to be 
-	    case insenstive. This feature should only be used if there is 
+            <p>Defines if the headers provided by the user are to be made 
+	    lower case or to be regarded as case sensitive.</p>
+            <p>The HTTP standard requires them to be 
+	    case insensitive. Use this feature only if there is 
 	    no other way to communicate with the server or for testing 
-	    purpose. Also note that when this option is used no headers 
-	    will be automatically added, all necessary headers have to be
-	    provided by the user. </p>
-	    <p>Defaults to <c>false</c>. </p>
+	    purpose. When this option is used, no headers 
+	    are automatically added. All necessary headers must be
+	    provided by the user.</p>
+	    <p>Default is <c>false</c>.</p>
 	  </item>
 
           <tag><c><![CDATA[socket_opts]]></c></tag>
           <item>
             <p>Socket options to be used for this and subsequent 
-	    request(s). </p>
-	    <p>Overrides any value set by the 
-	    <seealso marker="#set_options">set_options</seealso>
-	    function. </p>
-            <p>Note that the validity of the options are <em>not</em>
-	    checked in any way. </p>
-            <p>Note that this may change the socket behaviour 
-	    (see <seealso marker="kernel:inet#setopts/2">inet:setopts/2</seealso>) 
-	    for an already existing one, and therefore an already connected
-	    request handler. </p>
-            <p>By default the socket options set by the
-	    <seealso marker="#set_options">set_options/1,2</seealso> 
-	    function are used when establishing a connection. </p>
+	    requests.</p>
+	    <p>Overrides any value set by function
+	    <seealso marker="#set_options-1">set_options</seealso>.</p>
+            <p>The validity of the options is <em>not</em> checked by
+            the HTTP client they are assumed to be correct and passed
+            on to ssl application and inet driver, which may reject
+            them if they are not correct. Note that the current
+            implementation assumes the requests to the same host, port
+            combination will use the same socket options.
+	    </p>
+	    
+            <p>By default the socket options set by function
+	    <seealso marker="#set_options-1">set_options/[1,2]</seealso> 
+	     are used when establishing a connection.</p>
 	  </item>
 
           <tag><c><![CDATA[receiver]]></c></tag>
           <item>
-            <p>Defines how the client will deliver the result of an
-	    asynchronous request (<c>sync</c> has the value
-	    <c>false</c>). </p>
+            <p>Defines how the client delivers the result of an
+	    asynchronous request (<c>sync</c> has the value 
+	    <c>false</c>).</p>
 
             <taglist>
               <tag><c><![CDATA[pid()]]></c></tag>
               <item>
-	        <p>Message(s) will be sent to this process in the format: </p>
-<pre>
-{http, ReplyInfo}
-</pre>
+	        <p>Messages are sent to this process in the format 
+		<c>{http, ReplyInfo}</c>.</p>
 	      </item>
 
               <tag><c><![CDATA[function/1]]></c></tag>
               <item>
-	        <p>Information will be delivered to the receiver via calls 
-		to the provided fun: </p>
-<pre>
-Receiver(ReplyInfo)
-</pre>
+	        <p>Information is delivered to the receiver through calls 
+		to the provided fun <c>Receiver(ReplyInfo)</c>.</p>
   	      </item>
 
               <tag><c><![CDATA[{Module, Function, Args}]]></c></tag>
               <item>
-	        <p>Information will be delivered to the receiver via calls 
-		to the callback function: </p>
-<pre>
-apply(Module, Function, [ReplyInfo | Args])
-</pre>
+	        <p>Information is delivered to the receiver through calls 
+		to the callback function 
+		<c>apply(Module, Function, [ReplyInfo | Args])</c>.</p>
 	      </item>
-
             </taglist>
-            <p>In all of the above cases, <c>ReplyInfo</c> has the following
-              structure: </p>
+            <p>In all of these cases, <c>ReplyInfo</c> has the following
+              structure:</p>
 
 <pre>
 {RequestId, saved_to_file}
@@ -407,11 +501,10 @@ apply(Module, Function, [ReplyInfo | Args])
 {RequestId, Result}
 {RequestId, stream_start, Headers}
 {RequestId, stream_start, Headers, HandlerPid}
-{RequestId, stream,       BinBodyPart}
-{RequestId, stream_end,   Headers}
-</pre>
+{RequestId, stream, BinBodyPart}
+{RequestId, stream_end, Headers}</pre>
 
-            <p>Defaults to the <c>pid()</c> of the process calling the request 
+            <p>Default is the <c>pid</c> of the process calling the request 
 	    function (<c>self()</c>). </p>
 
 	    <marker id="ipv6_host_with_brackets"></marker>
@@ -419,276 +512,178 @@ apply(Module, Function, [ReplyInfo | Args])
 
           <tag><c><![CDATA[ipv6_host_with_brackets]]></c></tag>
           <item>
-            <p>When parsing the Host-Port part of an URI with a IPv6 address 
-	    with brackets, shall we retain those brackets (<c>true</c>) or 
-	    strip them (<c>false</c>). </p>
-            <p>Defaults to <c>false</c>. </p>
+            <p>Defines when parsing the Host-Port part of an URI with an IPv6 address 
+	    with brackets, if those brackets are to be retained (<c>true</c>) 
+	    or stripped (<c>false</c>).</p>
+            <p>Default is <c>false</c>.</p>
 	  </item>
 
         </taglist>
-
-        <marker id="cancel_request"></marker>
-      </desc>
-    </func>
-
-    <func>
-      <name>cancel_request(RequestId) -> </name>
-      <name>cancel_request(RequestId, Profile) -> ok</name>
-      <fsummary>Cancels an asynchronous HTTP-request.</fsummary>
-      <type>
-        <v>RequestId = request_id() - A unique identifier as returned
-        by request/4</v>
-	<v>Profile = profile() | pid() (when started <c>stand_alone</c>)</v>
-      </type>
-      <desc>
-        <p>Cancels an asynchronous HTTP-request. Note this does not guarantee
-	that the request response will not be delivered, as it is asynchronous the
-	the request may already have been completed when the cancellation arrives.
-	</p>
-
-        <marker id="set_options"></marker>
       </desc>
     </func>
 
+  
     <func>
       <name>set_options(Options) -> </name>
       <name>set_options(Options, Profile) -> ok | {error, Reason}</name>
       <fsummary>Sets options to be used for subsequent requests.</fsummary>
       <type>
         <v>Options = [Option]</v>
-        <v>Option = {proxy,                 {Proxy, NoProxy}} | 
-                    {https_proxy,           {Proxy, NoProxy}} | 
-	            {max_sessions,          MaxSessions} |
-	            {max_keep_alive_length, MaxKeepAlive} | 
-                    {keep_alive_timeout,    KeepAliveTimeout} |
-	            {max_pipeline_length,   MaxPipeline} |  
-                    {pipeline_timeout,      PipelineTimeout} | 
-                    {cookies,               CookieMode} | 
-                    {ipfamily,              IpFamily} | 
-                    {ip,                    IpAddress} | 
-                    {port,                  Port} | 
-                    {socket_opts,           socket_opts()} | 
-                    {verbose,               VerboseMode} </v>
-		    
+        <v>Option = {proxy, {Proxy, NoProxy}}</v>
+	<v>| {https_proxy, {Proxy, NoProxy}}</v>
+	<v>| {max_sessions, MaxSessions}</v>
+	<v>| {max_keep_alive_length, MaxKeepAlive}</v>
+	<v>| {keep_alive_timeout, KeepAliveTimeout}</v>
+	<v>| {max_pipeline_length, MaxPipeline}</v>
+	<v>| {pipeline_timeout, PipelineTimeout}</v>
+	<v>| {cookies, CookieMode}</v>
+	<v>| {ipfamily, IpFamily}</v>
+	<v>| {ip, IpAddress}</v>
+	<v>| {port, Port}</v>
+	<v>| {socket_opts, socket_opts()}</v>
+	<v>| {verbose, VerboseMode}</v>	    
         <v>Proxy = {Hostname, Port}</v>
-        <v>Hostname = string() </v>
-        <d>ex: "localhost" or "foo.bar.se"</d>
+        <v>Hostname = string()</v>
+        <d>Example: "localhost" or "foo.bar.se"</d>
         <v>Port = integer()</v>
-        <d>ex: 8080 </d>
+        <d>Example: 8080</d>
         <v>NoProxy = [NoProxyDesc]</v>
         <v>NoProxyDesc = DomainDesc | HostName | IPDesc</v>
         <v>DomainDesc = "*.Domain"</v>
-        <d>ex: "*.ericsson.se"</d>
+        <d>Example: "*.ericsson.se"</d>
         <v>IpDesc = string()</v>
-        <d>ex: "134.138" or "[FEDC:BA98" (all IP-addresses starting with 134.138 or FEDC:BA98), "66.35.250.150" or "[2010:836B:4179::836B:4179]" (a complete IP-address).</d>
-
-	<d>proxy defaults to {undefined, []} e.i. no proxy is configured and https_proxy defaults to
-	the value of proxy.</d>
-	
-	<v>MaxSessions = integer() </v>
-        <d>Default is <c>2</c>.
-	Maximum number of persistent connections to a host.</d>
-	<v>MaxKeepAlive = integer() </v>
-	<d>Default is <c>5</c>.
-	Maximum number of outstanding requests on the same connection to 
-	a host.</d>
-	<v>KeepAliveTimeout = integer() </v>
-	<d>Default is <c>120000</c> (= 2 min).
-	If a persistent connection is idle longer than the 
+        <d>Example: "134.138" or "[FEDC:BA98" 
+	(all IP addresses starting with 134.138 or FEDC:BA98), 
+	"66.35.250.150" or "[2010:836B:4179::836B:4179]" (a complete IP address).</d>
+	<d><c>proxy</c> defaults to <c>{undefined, []}</c>, 
+	that is, no proxy is configured and 
+	<c>https_proxy</c> defaults to the value of <c>proxy</c>.</d>	
+	<v>MaxSessions = integer()</v>
+        <d>Maximum number of persistent connections to a host.
+	Default is <c>2</c>.</d>
+	<v>MaxKeepAlive = integer()</v>
+	<d>Maximum number of outstanding requests on the same connection to 
+	a host. Default is <c>5</c>.</d>
+	<v>KeepAliveTimeout = integer()</v>
+	<d>If a persistent connection is idle longer than the 
 	<c>keep_alive_timeout</c> in milliseconds, 
-	the client will close the connection.
-	The server may also have such a time out but you should
-	not count on it!</d>
-	<v>MaxPipeline = integer() </v>
-	<d>Default is <c>2</c>.
-	Maximum number of outstanding requests on a pipelined connection 
-	to a host.</d>
-	<v>PipelineTimeout = integer() </v>
-	<d>Default is <c>0</c>,
-	which will result in pipelining not being used. 
-	If a persistent connection is idle longer than the 
+	the client closes the connection.
+	The server can also have such a time-out but do not take that for granted.
+	Default is <c>120000</c> (= 2 min).</d>
+	<v>MaxPipeline = integer()</v>
+	<d>Maximum number of outstanding requests on a pipelined connection 
+	to a host. Default is <c>2</c>.</d>
+	<v>PipelineTimeout = integer()</v>
+	<d>If a persistent connection is idle longer than the 
 	<c>pipeline_timeout</c> in milliseconds, 
-	the client will close the connection. </d>
-        <v>CookieMode = enabled | disabled | verify </v>
-        <d>Default is <c>disabled</c>.
-	If Cookies are enabled all valid cookies will automatically be 
-	saved in the client manager's cookie database. 
-	If the option <c>verify</c> is used the function <c>store_cookies/2</c>
-	has to be called for the cookies to be saved.</d>
-	<v>IpFamily = inet | inet6 | inet6fb4 </v>
-	<d>By default <c>inet</c>.
-	When it is set to <c>inet6fb4</c> you can use both ipv4 and ipv6. 
-	It first tries <c>inet6</c> and if that does not works falls back to <c>inet</c>. 
-	The option is here to provide a workaround for buggy ipv6 stacks to ensure that 
-	ipv4 will always work.</d>
-	<v>IpAddress = ip_address() </v>
-	<d>If the host has several network interfaces, this option specifies which one to use. 
-	See <seealso marker="kernel:gen_tcp#connect">gen_tcp:connect/3,4</seealso> for more info. </d>
-	<v>Port = integer() </v>
-	<d>Specify which local port number to use. 
-	See <seealso marker="kernel:gen_tcp#connect">gen_tcp:connect/3,4</seealso> for more info. </d>
+	the client closes the connection. Default is <c>0</c>,
+	which results in pipelining not being used.</d>
+        <v>CookieMode = enabled | disabled | verify</v>
+        <d>If cookies are enabled, all valid cookies are automatically 
+	saved in the cookie database of the client manager.
+	If option <c>verify</c> is used, function <c>store_cookies/2</c>
+	has to be called for the cookies to be saved. 
+	Default is <c>disabled</c>.</d>
+	<v>IpFamily = inet | inet6 </v>
+	<d>Default is <c>inet</c>.</d>
+	<v>IpAddress = ip_address()</v>
+	<d>If the host has several network interfaces, this option specifies 
+	which one to use. 
+	See <seealso marker="kernel:gen_tcp#connect">gen_tcp:connect/3,4</seealso> 
+	for details.</d>
+	<v>Port = integer()</v>
+	<d>Local port number to use. 
+	See <seealso marker="kernel:gen_tcp#connect">gen_tcp:connect/3,4</seealso> 
+	for details.</d>
 	<v>socket_opts() = [socket_opt()]</v>
 	<d>The options are appended to the socket options used by the 
-	client. </d>
+	client.</d>
 	<d>These are the default values when a new request handler
 	is started (for the initial connect). They are passed directly 
-          to the underlying transport (gen_tcp or ssl) <em>without</em> 
-	verification! </d>
-	<v>VerboseMode = false | verbose | debug | trace </v>
+        to the underlying transport (<c>gen_tcp</c> or <c>SSL</c>) 
+	<em>without</em> verification.</d>
+	<v>VerboseMode = false | verbose | debug | trace</v>
 	<d>Default is <c>false</c>.
 	This option is used to switch on (or off) 
-	different levels of erlang trace on the client. 
+	different levels of Erlang trace on the client. 
 	It is a debug feature.</d>
-	<v>Profile = profile() | pid() (when started <c>stand_alone</c>)</v>
+	<v>Profile = profile() | pid()</v>
+	<d>When started <c>stand_alone</c> only the pid can be used.</d>
       </type>
       <desc>
 	<p>Sets options to be used for subsequent requests.</p>
 	<note>
-	  <p>If possible the client will keep its connections
-	  alive and use persistent connections
-	  with  or without pipeline depending on configuration
+	  <p>If possible, the client keeps its connections
+	  alive and uses persistent connections
+	  with or without pipeline depending on configuration
 	  and current circumstances. The HTTP/1.1 specification does not
-	  provide a guideline for how many requests would be
-	  ideal to be sent on a persistent connection,
-	  this very much depends on the
-	  application. Note that a very long queue of requests may cause a
-	  user perceived delay as earlier requests may take a long time
-	  to complete. The HTTP/1.1 specification does suggest a
-	  limit of 2 persistent connections per server, which is the
-	  default value of the <c>max_sessions</c> option. </p>
+	  provide a guideline for how many requests that are
+	  ideal to be sent on a persistent connection.
+	  This depends much on the application.</p>
+	  <p>A long queue of requests can cause a
+	  user-perceived delay, as earlier requests can take a long time
+	  to complete. The HTTP/1.1 specification suggests a
+	  limit of two persistent connections per server, which is the
+	  default value of option <c>max_sessions</c>.</p>
 	</note>
 
         <marker id="get_options"></marker>
       </desc>
     </func>
-    
-    <func>
-      <name>get_options(OptionItems) -> {ok, Values} | {error, Reason}</name>
-      <name>get_options(OptionItems, Profile) -> {ok, Values} | {error, Reason}</name>
-      <fsummary>Gets the currently used options.</fsummary>
-      <type>
-        <v>OptionItems = all | [option_item()]</v>
-	<v>option_item() = proxy |
-	                   https_proxy
-                           max_sessions | 
-			   keep_alive_timeout | 
-	                   max_keep_alive_length | 
-			   pipeline_timeout | 
-			   max_pipeline_length | 
-			   cookies | 
-			   ipfamily | 
-			   ip | 
-			   port | 
-			   socket_opts | 
-	                   verbose</v>
-	<v>Profile = profile() | pid() (when started <c>stand_alone</c>)</v>
-        <v>Values = [{option_item(), term()}]</v>
-        <v>Reason = term() </v>
-      </type>
-      <desc>
-        <p>Retrieves the options currently used by the client.</p>
-
-        <marker id="stream_next"></marker>
-      </desc>
-    </func>
-    
-     <func>
-      <name>stream_next(Pid) -> ok</name>
-      <fsummary> Triggers the next message to be streamed, e.i.
-	same behavior as active once for sockets.
-      </fsummary>
-      <type>
-        <v>Pid = pid() - as received in the stream_start message</v>
-      </type>
-      <desc>
-        <p>Triggers the next message to be streamed, e.i.
-	same behavior as active once for sockets. </p>
-
-        <marker id="verify_cookies"></marker>
-        <marker id="store_cookies"></marker>
-      </desc>
-    </func>
-    
+     
     <func>
       <name>store_cookies(SetCookieHeaders, Url) -> </name>
       <name>store_cookies(SetCookieHeaders, Url, Profile) -> ok | {error, Reason}</name>
-      <fsummary>Saves the cookies defined in SetCookieHeaders in the client profile's cookie database.</fsummary>
+      <fsummary>Saves the cookies defined in <c>SetCookieHeaders</c> in the 
+      client profile cookie database.</fsummary>
       <type>
         <v>SetCookieHeaders = headers() - where field = "set-cookie"</v>
         <v>Url = url()</v>
-	<v>Profile = profile() | pid() (when started <c>stand_alone</c>)</v>
-      </type>
-      <desc>
-        <p>Saves the cookies defined in SetCookieHeaders
-	in the client profile's cookie database. You need to
-	call this function if you have set the option <c>cookies</c> 
-	to <c>verify</c>.
-	If no profile is specified the default profile will be used. </p>
-
-        <marker id="cookie_header"></marker>
-      </desc>
-    </func>
-
-    <func>
-      <name>cookie_header(Url) -> </name>
-      <name>cookie_header(Url, Profile | Opts) -> header() | {error, Reason}</name>
-      <name>cookie_header(Url, Opts, Profile) -> header() | {error, Reason}</name>
-      <fsummary>Returns the cookie header that would be sent when
-      making a request to Url using the profile <c>Profile</c>.</fsummary>
-      <type>
-        <v>Url = url()</v>
-        <v>Opts = [cookie_header_opt()]</v>
-	<v>Profile = profile() | pid() (when started <c>stand_alone</c>)</v>
-        <v>cookie_header_opt() = {ipv6_host_with_brackets, boolean()}</v>
+	<v>Profile = profile() | pid()</v>
+	<d>When started <c>stand_alone</c> only the pid can be used.</d>
       </type>
       <desc>
-        <p>Returns the cookie header that would be sent
-	when making a request to <c>Url</c> using the profile <c>Profile</c>.
-	If no profile is specified the default profile will be used. </p>
-	<p>The option <c>ipv6_host_with_bracket</c> deals with how to 
-	parse IPv6 addresses. 
-	See the <c>Options</c> argument of the 
-	<seealso marker="#request2">request/4,5</seealso> for more info. </p>
-
-        <marker id="reset_cookies"></marker>
+        <p>Saves the cookies defined in <c>SetCookieHeaders</c>
+	in the client profile cookie database.
+	Call this function if option <c>cookies</c> is set to <c>verify</c>.
+	If no profile is specified, the default profile is used.</p>
       </desc>
     </func>
 
-
     <func>
-      <name>reset_cookies() -> void()</name>
-      <name>reset_cookies(Profile) -> void()</name>
-      <fsummary>Reset the cookie database.</fsummary>
+      <name>stream_next(Pid) -> ok</name>
+      <fsummary>Triggers the next message to be streamed, that is,
+	the same behavior as active one for sockets.
+      </fsummary>
       <type>
-	<v>Profile = profile() | pid() (when started <c>stand_alone</c>)</v>
+        <v>Pid = pid()</v>
+	<d>As received in the <c>stream_start message</c></d>
       </type>
       <desc>
-        <p>Resets (clears) the cookie database for the specified 
-	<c>Profile</c>. If no profile is specified the default profile 
-	will be used. </p>
+        <p>Triggers the next message to be streamed, that is,
+	the same behavior as active ones for sockets.</p>
 
-        <marker id="which_cookies"></marker>
+        <marker id="verify_cookies"></marker>
+        <marker id="store_cookies"></marker>
       </desc>
     </func>
-
-
+    
     <func>
       <name>which_cookies() -> cookies()</name>
       <name>which_cookies(Profile) -> cookies()</name>
-      <fsummary>Dumps out the entire cookie database.</fsummary>
+      <fsummary>Dumps the entire cookie database.</fsummary>
       <type>
-	<v>Profile = profile() | pid() (when started <c>stand_alone</c>)</v>
+	<v>Profile = profile() | pid()</v>
+	<d>When started <c>stand_alone</c> only the pid can be used.</d>
 	<v>cookies() = [cookie_stores()]</v>
 	<v>cookie_stores() = {cookies, cookies()} | {session_cookies, cookies()}</v>
 	<v>cookies() = [cookie()]</v>
 	<v>cookie() = term()</v>
       </type>
       <desc>
-        <p>This function produces a list of the entire cookie database.
-	It is intended for debugging/testing purposes. 
-	If no profile is specified the default profile will be used. </p>
-
-        <marker id="which_sessions"></marker>
+        <p>Produces a list of the entire cookie database.
+	Intended for debugging/testing purposes. 
+	If no profile is specified, the default profile is used.</p>
       </desc>
     </func>
 
@@ -697,41 +692,29 @@ apply(Module, Function, [ReplyInfo | Args])
       <name>which_sessions(Profile) -> session_info()</name>
       <fsummary>Produces a slightly processed dump of the sessions database.</fsummary>
       <type>
-	<v>Profile = profile() | pid() (when started <c>stand_alone</c>)</v>
+	<v>Profile = profile() | pid()</v>
+	<d>When started <c>stand_alone</c> only the pid can be used.</d>
 	<v>session_info() = {GoodSessions, BadSessions, NonSessions}</v>
 	<v>GoodSessions = session()</v>
 	<v>BadSessions = tuple()</v>
 	<v>NonSessions = term()</v>
       </type>
       <desc>
-        <p>This function produces a slightly processed dump of the session 
+        <p>Produces a slightly processed dump of the session 
 	database. It is intended for debugging. 
-	If no profile is specified the default profile will be used. </p>
-
-        <marker id="info"></marker>
+	If no profile is specified, the default profile is used.</p>
       </desc>
     </func>
 
-    <func>
-      <name>info() -> list()</name>
-      <name>info(Profile) -> list()</name>
-      <fsummary>Produces a list of miscelleneous info</fsummary>
-      <type>
-	<v>Profile = profile() | pid() (when started <c>stand_alone</c>)</v>
-      </type>
-      <desc>
-        <p>This function produces a list of miscelleneous info. 
-	It is intended for debugging. 
-	If no profile is specified the default profile will be used. </p>
-      </desc>
-    </func>
+  
   </funcs>
 
   <section>
     <title>SEE ALSO</title>
-    <p>RFC 2616, <seealso marker="inets">inets(3)</seealso>,
-      <seealso marker="kernel:gen_tcp">gen_tcp(3)</seealso>, 
-      <seealso marker="ssl:ssl">ssl(3)</seealso>
+    <p><url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>, 
+    <seealso marker="inets">inets(3)</seealso>,
+    <seealso marker="kernel:gen_tcp">gen_tcp(3)</seealso>, 
+    <seealso marker="ssl:ssl">ssl(3)</seealso>
     </p>
   </section>
   
diff --git a/lib/inets/doc/src/httpd.xml b/lib/inets/doc/src/httpd.xml
index 7ea9b9318f..2a4aea41c2 100644
--- a/lib/inets/doc/src/httpd.xml
+++ b/lib/inets/doc/src/httpd.xml
@@ -31,191 +31,191 @@
   </header>
   <module>httpd</module> 
   <modulesummary>An implementation of an HTTP
-    1.1 compliant Web server, as defined in RFC 2616.
+    1.1 compliant web server, as defined in <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>
   </modulesummary>
   <description>
-    <p>Documents the HTTP server start options, some administrative
-      functions and also specifies the Erlang Web server callback
-      API</p>
+    <p>This module provides the HTTP server start options, some administrative
+      functions, and specifies the Erlang web server callback
+      API.</p>
   </description>
   
   <section>
-    <title>COMMON DATA TYPES </title>
+    <title>DATA TYPES</title>
     <p>Type definitions that are used more than once in
       this module:</p>
-    <p><c>boolean() = true | false </c></p>
-    <p><c>string() = list of ASCII characters</c></p>
-    <p><c>path() = string() - representing a file or directory path.</c></p>
-    <p><c> ip_address() = {N1,N2,N3,N4}  % IPv4
+    <p><c>boolean() = true | false</c></p>
+    <p><c>string()</c> = list of ASCII characters</p>
+    <p><c>path() = string()</c> representing a file or a directory path</p>
+    <p><c> ip_address() = {N1,N2,N3,N4} % IPv4
        | {K1,K2,K3,K4,K5,K6,K7,K8}  % IPv6</c></p>
-    <p><c>hostname() = string() - representing a host ex "foo.bar.com"</c></p>
+    <p><c>hostname() = string()</c> representing a host, for example, 
+    "foo.bar.com"</p>
     <p><c>property() = atom()</c></p>
     
   </section>
 
   <section>
-    <title>ERLANG HTTP SERVER SERVICE START/STOP </title>
-    <p>A web server can be configured to start when starting the inets
-    application or started dynamically in runtime by calling the
-    Inets application API <c>inets:start(httpd, ServiceConfig)</c>, or
+    <title>ERLANG HTTP SERVER SERVICE START/STOP</title>
+    <p>A web server can be configured to start when starting the <c>Inets</c>
+    application, or dynamically in runtime by calling the
+    <c>Inets</c> application API <c>inets:start(httpd, ServiceConfig)</c> or
     <c>inets:start(httpd, ServiceConfig, How)</c>,
-    see <seealso marker="inets">inets(3)</seealso> Below follows a
-    description of the available configuration options, also called
-    properties.</p>
+    see <seealso marker="inets">inets(3)</seealso>.
+    The configuration options, also called
+    properties, are as follows:</p>
 
     <marker id="props_file"></marker>
-    <p><em>File properties</em></p>
+    <p><em>File Properties</em></p>
 
     <p>When the web server is started
-    at application start time the properties should be fetched from a
-    configuration file that could consist of a regular erlang property
-    list, e.i.  <c>[{Option, Value}] </c> where <c> Option = property()
+    at application start time, the properties are to be fetched from a
+    configuration file that can consist of a regular Erlang property
+    list, that is, <c>[{Option, Value}]</c>, where <c> Option = property()
     </c> and <c>Value = term()</c>, followed by a full stop, or for
-    backwards compatibility an Apache like configuration file. If the
-    web server is started dynamically at runtime you may still specify
-    a file but you could also just specify the complete property
+    backwards compatibility, an Apache-like configuration file. If the
+    web server is started dynamically at runtime,
+    a file can still be specified but also the complete property
     list.</p>
     
     <taglist>
       <marker id="prop_proplist_file"></marker>
       <tag>{proplist_file, path()}</tag>
       <item>
-	<p>If this property is defined inets will expect to find
-	all other properties defined in this file. Note that the
+	<p>If this property is defined, <c>Inets</c> expects to find
+	all other properties defined in this file. The
 	file must include all properties listed under mandatory
-	properties. </p>
+	properties.</p>
       </item>
 
       <marker id="prop_file"></marker>
       <tag>{file, path()}</tag>
       <item> 
-	<p>If this property is defined inets will expect to find all 
-	other properties defined in this file, that uses Apache like 
-	syntax. Note that the file must include all properties listed 
-	under mandatory properties. The Apache like syntax is the property, 
+	<p>If this property is defined, <c>Inets</c> expects to find all 
+	other properties defined in this file, which uses Apache-like 
+	syntax. The file must include all properties listed 
+	under mandatory properties. The Apache-like syntax is the property, 
 	written as one word where each new word begins with a capital, 
-	followed by a white-space followed by the value followed by a 
-	new line. Ex: </p>
-
+	followed by a white-space, followed by the value, followed by a 
+	new line.</p>
+	<p>Example:</p>
 	<code>
-{server_root, "/urs/local/www"} -> ServerRoot /usr/local/www
-	</code>
+{server_root, "/urs/local/www"} -> ServerRoot /usr/local/www</code>
 	  
-	<p>With a few exceptions, that are documented
+	<p>A few exceptions are documented
 	  for each property that behaves differently,
-	  and the special case {directory, {path(), PropertyList}} and
-	  {security_directory, {Dir, PropertyList}} that are represented
+	  and the special cases <c>{directory, {path(), PropertyList}}</c> 
+	  and <c>{security_directory, {Dir, PropertyList}}</c>, are represented
 	  as:</p>
 	<pre>
 	  <![CDATA[
 <Directory Dir>
  <Properties handled as described above> 
 </Directory>
-         ]]>
-	</pre>
+         ]]></pre>
       </item>
     </taglist>
     <note>
-      <p>The properties proplist_file and file are mutually exclusive.</p>
+	<p>The properties <c>proplist_file</c> and <c>file</c> are mutually exclusive. Also newer properties may not be supported as Apache-like options, this is a legacy feature.</p>
     </note>
 
     <marker id="props_mand"></marker>
-    <p><em>Mandatory properties</em></p>
+    <p><em>Mandatory Properties</em></p>
     <taglist>
       <marker id="prop_port"></marker>
       <tag>{port, integer()} </tag>
       <item> 
-	<p>The port that the HTTP server shall listen on.
+	<p>The port that the HTTP server listen to.
 	If zero is specified as port, an arbitrary available port
-	will be picked and you can use the httpd:info/2 function to find
-	out which port was picked. </p>
+	is picked and function <c>httpd:info/2</c> can be used to
+	determine which port was picked.</p>
       </item>
 
       <marker id="prop_server_name"></marker>
-      <tag>{server_name, string()} </tag>
+      <tag>{server_name, string()}</tag>
       <item>
-	<p>The name of your server, normally a fully qualified domain name. </p>
+	<p>The name of your server, normally a fully qualified domain name.</p>
       </item>
 
       <marker id="prop_server_root"></marker>
-      <tag>{server_root, path()} </tag>
+      <tag>{server_root, path()}</tag>
       <item> 
-	<p>Defines the server's home directory where log files etc can
-	be stored. Relative paths specified in other properties refer
-	to this directory. </p>
+	<p>Defines the home directory of the server, where log files, and so on, 
+	can be stored. Relative paths specified in other properties refer
+	to this directory.</p>
       </item>
 
       <marker id="prop_doc_root"></marker>
       <tag>{document_root, path()}</tag>
       <item>
-	Defines the top directory for the documents that
-	are available on the HTTP server.
+	<p>Defines the top directory for the documents that
+	are available on the HTTP server.</p>
       </item>
     </taglist>
 
     <marker id="props_comm"></marker>
-    <p><em>Communication properties</em> </p>
+    <p><em>Communication Properties</em></p>
     <taglist>
       <marker id="prop_bind_address"></marker>
-      <tag>{bind_address, ip_address() | hostname() | any} </tag>
+      <tag>{bind_address, ip_address() | hostname() | any}</tag>
       <item>
-	<p>Defaults to <c>any</c>. Note that <c>any</c> is denoted <em>*</em> 
-	in the apache like configuration file. </p>
+	<p>Default is <c>any</c>. <c>any</c> is denoted <em>*</em> 
+	in the Apache-like configuration file.</p>
       </item>
 
       <marker id="profile"></marker>
       <tag>{profile, atom()}</tag>
       <item>
-        <p>Used together with <seealso marker="prop_bind_address"><c>bind_address</c></seealso>
-	and <seealso marker="prop_port"><c>port</c></seealso> to uniquely identify
+        <p>Used together with <seealso marker="#prop_bind_address"><c>bind_address</c></seealso>
+	and <seealso marker="#prop_port"><c>port</c></seealso> to uniquely identify
 	a HTTP server. This can be useful in a virtualized environment,
 	where there can
 	be more that one server that has the same bind_address and port.
 	If this property is not explicitly set, it is assumed that the
-	<seealso marker="prop_bind_address"><c>bind_address</c></seealso> and
-	<seealso marker="prop_port"><c>port</c></seealso>uniquely identifies the HTTP server.
+	<seealso marker="#prop_bind_address"><c>bind_address</c></seealso> and
+	<seealso marker="#prop_port"><c>port</c></seealso>uniquely identifies the HTTP server.
 	</p>
       </item>
 
       <marker id="prop_socket_type"></marker>
       <tag>{socket_type, ip_comm | {essl, Config::proplist()}}</tag>
       <item>
-	<p> For ssl configuration options see <seealso marker="ssl:ssl#listen-2">ssl:listen/2</seealso> </p>
-	<p>Defaults to <c>ip_comm</c>. </p> 
+	<p>For <c>SSL</c> configuration options, see 
+	<seealso marker="ssl:ssl#listen-2">ssl:listen/2</seealso>.</p>
+	<p>Default is <c>ip_comm</c>.</p> 
       </item>
 
       <marker id="prop_ipfamily"></marker>
       <tag>{ipfamily, inet | inet6 | inet6fb4}</tag>
       <item>
-	<p>Defaults to <c>inet6fb4. </c> </p>
-        <p>Note that this option is only used when the option 
-	<c>socket_type</c> has the value <c>ip_comm</c>. </p>
+        <p>This option is only used when option 
+	<c>socket_type</c> has value <c>ip_comm</c>.</p>
+	<p>Default is <c>inet6fb4</c>.</p>
       </item>
 
       
       <marker id="prop_minimum_bytes_per_second"></marker>
       <tag>{minimum_bytes_per_second, integer()}</tag>
       <item>
-	<p>If given, sets a minimum bytes per second value for connections.</p>
-	<p>If the value is not reached, the socket will close for that connection.</p>
-	<p>The option is good for reducing the risk of "slow dos" attacks.</p>
+	<p>If given, sets a minimum of bytes per second value for connections.</p>
+	<p>If the value is unreached, the socket closes for that connection.</p>
+	<p>The option is good for reducing the risk of "slow DoS" attacks.</p>
       </item>
     </taglist>
 
     <marker id="props_api_modules"></marker>
-    <p><em>Erlang Web server API modules</em> </p>
+    <p><em>Erlang Web Server API Modules</em> </p>
     <taglist>
       <marker id="prop_modules"></marker>
       <tag>{modules, [atom()]} </tag>
       <item>
-	<p>Defines which modules the HTTP server will use to handle
-	requests. Defaults to: <c>[mod_alias, mod_auth, mod_esi,
+	<p>Defines which modules the HTTP server uses when handling
+	requests. Default is <c>[mod_alias, mod_auth, mod_esi,
 	mod_actions, mod_cgi, mod_dir, mod_get, mod_head, mod_log,
-	mod_disk_log] </c> 
-	Note that some mod-modules are dependent on
-	others, so the order can not be entirely arbitrary. See the
-	<seealso marker="http_server"> Inets Web server Modules in the
-	Users guide</seealso> for more information. </p>
+	mod_disk_log]</c>. 
+	Notice that some <c>mod</c>-modules are dependent on
+	others, so the order cannot be entirely arbitrary. See the
+	<seealso marker="http_server">Inets Web Server Modules</seealso> in the
+	User's Guide for details.</p>
       </item>
     </taglist>
     
@@ -227,412 +227,413 @@
       <tag>{customize, atom()}</tag>
       <item> 
 	<p>A callback module to customize the inets HTTP servers behaviour
-	see <seealso marker="http_custom_api"> httpd_custom_api</seealso> </p>
+	see <seealso marker="httpd_custom_api"> httpd_custom_api</seealso> </p>
       </item>
       
       <marker id="prop_disable_chunked_encoding"></marker>
       <tag>{disable_chunked_transfer_encoding_send, boolean()}</tag>
       <item> 
-	<p>This property allows you to disable chunked
-	transfer-encoding when sending a response to a HTTP/1.1
-	client, by default this is false. </p>
+	<p>Allows you to disable chunked
+	transfer-encoding when sending a response to an HTTP/1.1
+	client. Default is <c>false</c>.</p>
       </item>
       
       <marker id="prop_keep_alive"></marker>
       <tag>{keep_alive, boolean()}</tag>
       <item>
-	<p>Instructs the server whether or not to use persistent
+	<p>Instructs the server whether to use persistent
 	connections when the client claims to be HTTP/1.1
-	compliant, default is true. </p>
+	compliant. Default is <c>true</c>.</p>
       </item>
       
       <marker id="prop_keep_alive_timeout"></marker>
       <tag>{keep_alive_timeout, integer()}</tag>
       <item>
-	<p>The number of seconds the server will wait for a
+	<p>The number of seconds the server waits for a
 	subsequent request from the client before closing the
-	connection. Default is 150. </p>
+	connection. Default is <c>150</c>.</p>
       </item>
       
       <marker id="prop_max_body_size"></marker>
       <tag>{max_body_size, integer()}</tag>
       <item>
-	<p>Limits the size of the message body of HTTP request.
-	By the default there is no limit. </p>
+	<p>Limits the size of the message body of an HTTP request.
+	Default is no limit.</p>
       </item>
       
       <marker id="prop_max_clients"></marker>
       <tag>{max_clients, integer()}</tag>
       <item> 
 	<p>Limits the number of simultaneous requests that can be
-	supported. Defaults to 150. </p>
+	supported. Default is <c>150</c>.</p>
       </item>
 
       <marker id="prop_max_header_size"></marker>
       <tag>{max_header_size, integer()}</tag>
       <item>
-	<p>Limits the size of the message header of HTTP request.
-	Defaults to 10240. </p>
+	<p>Limits the size of the message header of an HTTP request.
+	Default is <c>10240</c>.</p>
       </item>
 
       <marker id="prop_max_content_length"></marker>
       <tag>{max_content_length, integer()}</tag>
       <item>
-	<p>Maximum Content-Length in an incoming request, in bytes. Requests
-	with content larger than this are answered with Status 413.
-	Defaults to 100000000 (100 MB).
+	<p>Maximum content-length in an incoming request, in bytes. Requests
+	with content larger than this are answered with status 413.
+	Default is <c>100000000</c> (100 MB).
 	</p>
       </item>
 
       <marker id="prop_max_uri"></marker>
       <tag>{max_uri_size, integer()}</tag>
       <item>
-	<p>Limits the size of the HTTP request URI. By
-	default there is no limit. </p>
+	<p>Limits the size of the HTTP request URI.
+	Default is no limit.</p>
       </item>
       
       <marker id="prop_max_keep_alive_req"></marker>
       <tag>{max_keep_alive_request, integer()}</tag>
       <item>
-	<p>The number of request that a client can do on one
+	<p>The number of requests that a client can do on one
 	connection. When the server has responded to the number of
-	requests defined by max_keep_alive_requests the server close the
-	connection. The server will close it even if there are queued
-	request. Defaults to no limit. </p>
+	requests defined by <c>max_keep_alive_requests</c>, the server 
+	closes the connection. The server closes it even if there are 
+	queued request. Default is no limit.</p>
       </item>   
     </taglist>
     
     <marker id="props_admin"></marker>
-    <p><em>Administrative properties</em></p>
+    <p><em>Administrative Properties</em></p>
     <taglist> 
       <marker id="prop_mime_types"></marker>
       <tag>{mime_types, [{MimeType, Extension}] | path()}</tag>
       <item>
-	<p>Where MimeType = string() and Extension = string().
+	<p><c>MimeType = string()</c> and <c>Extension = string()</c>.
 	  Files delivered to the client are MIME typed according to RFC
           1590. File suffixes are mapped to MIME types before file delivery.
           The mapping between file suffixes and MIME types can be specified
-	  as an Apache like file as well as directly in the property list. Such
-          a file may look like:</p>
+	  as an Apache-like file or directly in the property list. Such
+          a file can look like the follwoing:</p>
         <pre>
 # MIME type	Extension  
 text/html	html htm
-text/plain	asc txt
-        </pre>
+text/plain	asc txt</pre>
 	
-	<p>Defaults to  [{"html","text/html"},{"htm","text/html"}]</p>
+	<p>Default is [{"html","text/html"},{"htm","text/html"}].</p>
       </item>
 
       <marker id="prop_mime_type"></marker>
       <tag>{mime_type, string()}</tag>
       <item>
-	<p>When the server is asked to provide a document type which
-	cannot be determined by the MIME Type Settings, the server will
-	use this default type. </p>
+	<p>When the server is asked to provide a document type that
+	cannot be determined by the MIME Type Settings, the server
+	uses this default type.</p>
       </item>
   
       <marker id="prop_server_admin"></marker>
       <tag>{server_admin, string()}</tag>
       <item>
-	<p>ServerAdmin defines the email-address of the server
-	administrator, to be included in any error messages returned by
-	the server. </p>
+	<p>Defines the email-address of the server
+	administrator to be included in any error messages returned by
+	the server.</p>
       </item>
 
       <marker id="prop_server_tokens"></marker>
       <tag>{server_tokens, none|prod|major|minor|minimal|os|full|{private, string()}}</tag>
       <item>
-	<p>ServerTokens defines how the value of the server header 
-	should look. </p>
-	<p>Example: Assuming the version of inets is 5.8.1, 
-	here is what the server header string could look like for
-	the different values of server-tokens:  </p>
-	<pre>
-none                  ""  % A Server: header will not be generated
-prod                  "inets"
-major                 "inets/5"
-minor                 "inets/5.8"
-minimal               "inets/5.8.1"
-os                    "inets/5.8.1 (unix)"
-full                  "inets/5.8.1 (unix/linux) OTP/R15B"
-{private, "foo/bar"}  "foo/bar"
-	</pre>
-	<p>By default, the value is as before, which is <c>minimal</c>. </p>
+	<p>Defines the look of the value of the server header.</p>
+	<p>Example: Assuming the version of <c>Inets</c> is 5.8.1, 
+	the server header string can look as follows for
+	the different values of server-tokens:</p>
+	<taglist>
+       <tag><c>none</c></tag>
+       <item><p>""  % A Server: header will not be generated</p></item>
+       <tag><c>prod</c></tag>
+       <item><p>"inets"</p></item>
+       <tag><c>major</c></tag>
+       <item><p>"inets/5"</p></item>
+       <tag><c>minor</c></tag>
+       <item><p>"inets/5.8"</p></item>
+       <tag><c>minimal</c></tag>
+       <item><p>"inets/5.8.1"</p></item>
+       <tag><c>os</c></tag>
+       <item><p>"inets/5.8.1 (unix)"</p></item>
+       <tag><c>full</c></tag>
+       <item><p>"inets/5.8.1 (unix/linux) OTP/R15B"</p></item>
+       <tag><c>{private, "foo/bar"}</c></tag>
+       <item><p>"foo/bar"</p></item>
+     </taglist>
+	<p>By default, the value is as before, that is, <c>minimal</c>.</p>
       </item>
 
       <marker id="prop_log_format"></marker>
       <tag>{log_format, common | combined}</tag>
       <item>
-	<p>Defines if access logs should be written according to the common
-	log format or to the extended common log format.
-	The <c>common</c> format is one line that looks like this:
-        <c>remotehost rfc931 authuser [date] "request" status bytes</c></p> 
-
-	<pre>
-remotehost
-	Remote
-rfc931
-	The client's remote username (RFC 931). 
-authuser
-	The username with which the user authenticated 
-        himself. 
-[date]
-	Date and time of the request (RFC 1123). 
-"request"
-	The request line exactly as it came from the client
-        (RFC 1945). 
-status
-	The HTTP status code returned to the client 
-        (RFC 1945). 
-bytes
-	The content-length of the document transferred. 
-        </pre>
-
-	<p>The <c>combined</c> format is on line that look like this:
+	<p>Defines if access logs are to be written according to the <c>common</c>
+	log format or the extended common log format.
+	The <c>common</c> format is one line looking like this:
+        <c>remotehost rfc931 authuser [date] "request" status bytes</c>.</p> 
+	<p>Here:</p>
+	<taglist>
+	  <tag><c>remotehost</c></tag>
+	  <item>Remote.</item>
+	  <tag><c>rfc931</c></tag>
+	  <item>The remote username of the client (<url href="http://www.ietf.org/rfc/rfc931.txt">RFC 931</url>).</item>
+	  <tag><c>authuser</c></tag>
+	  <item>The username used for authentication.</item>
+	  <tag><c>[date]</c></tag>
+	  <item>Date and time of the request (<url href="http://www.ietf.org/rfc/rfc1123.txt">RFC 1123</url>).</item>
+	  <tag><c>"request"</c></tag>
+	  <item>The request line as it came from the client  (<url href="http://www.ietf.org/rfc/rfc1945.txt">RFC 1945</url>).</item>
+	  <tag><c>status</c></tag>
+	  <item>The HTTP status code returned to the client (<url href="http://www.ietf.org/rfc/rfc1945.txt">RFC 1945</url>).</item>
+	  <tag><c>bytes</c></tag>
+	  <item>The content-length of the document transferred.</item>
+	</taglist>
+
+	<p>The <c>combined</c> format is one line looking like this:
 	<c>remotehost rfc931 authuser [date] "request" status bytes "referer" "user_agent" </c></p>
+	<p>In addition to the earlier:</p>
+	<taglist>
+	  <tag><c>"referer"</c></tag>
+	  <item>The URL the client was on before
+	requesting the URL (if it could not be determined, 
+	a minus sign is placed in this field).</item>
+	  <tag><c>"user_agent"</c></tag>
+	  <item>The software the client claims to be using (if it
+	could not be determined, a minus sign is placed in
+	this field).</item>
+	</taglist>
 	
-	<pre>
-"referer"
-	The url the client was on before
-	requesting your url. (If it could not be determined 
-	a minus sign will be placed in this field)
-"user_agent"
-	The software the client claims to be using. (If it
-	could not be determined a minus sign will be placed in
-	this field)
-	</pre>
-	
-	<p>This affects the access logs written by mod_log and mod_disk_log.
-	</p>
-	
+	<p>This affects the access logs written by <c>mod_log</c> and 
+	<c>mod_disk_log</c>.
+	</p>	
       </item>      
 
       <marker id="prop_elog_format"></marker>
       <tag>{error_log_format, pretty | compact}</tag>
       <item>
-	<p>Defaults to pretty.  If the error log is meant to be read
-	directly by a human <c>pretty</c> will be the best
-	option. <c>pretty</c> has the format corresponding to:
-	</p>
+	<p>Default is <c>pretty</c>. If the error log is meant to be read
+	directly by a human, <c>pretty</c> is the best option.</p>
+	<p><c>pretty</c> has a format corresponding to:</p>
 	
-	<code>io:format("[~s] ~s, reason: ~n ~p ~n~n", [Date, Msg, Reason]).
-	</code>
+	<code>io:format("[~s] ~s, reason: ~n ~p ~n~n", [Date, Msg, Reason]).</code>
 
-	<p><c>compact</c> has the format corresponding to:</p>
+	<p><c>compact</c> has a format corresponding to:</p>
 	
-	<code>io:format("[~s] ~s, reason: ~w ~n", [Date, Msg, Reason]).
-	</code>
+	<code>io:format("[~s] ~s, reason: ~w ~n", [Date, Msg, Reason]).</code>
 
-	<p>This affects the error logs written by mod_log and mod_disk_log.
+	<p>This affects the error logs written by <c>mod_log</c> and 
+	<c>mod_disk_log</c>.
 	</p>
       </item>
       
     </taglist>
    
     <marker id="props_alias"></marker>
-    <p><em>URL aliasing properties - requires mod_alias</em></p>
+    <p><em>URL Aliasing Properties - Requires mod_alias</em></p>
     <taglist>
       <marker id="prop_alias"></marker>
       <tag>{alias, {Alias, RealName}}</tag>
       <item>
-	<p>Where Alias = string() and RealName = string(). 
-	The Alias property allows documents to be stored in the local file
-	system instead of the document_root location. URLs with a path that
-	begins with url-path is mapped to local files that begins with
+	<p><c>Alias = string()</c> and <c>RealName = string()</c>. 
+	<c>alias</c> allows documents to be stored in the local file
+	system instead of the <c>document_root</c> location. URLs with a path
+	beginning with url-path is mapped to local files beginning with
 	directory-filename, for example:
 	
 	<code>{alias, {"/image", "/ftp/pub/image"}}</code>
 	
-	and an access to http://your.server.org/image/foo.gif would refer to
-	the file /ftp/pub/image/foo.gif. </p>
+	Access to http://your.server.org/image/foo.gif would refer to
+	the file /ftp/pub/image/foo.gif.</p>
       </item>
 
       <marker id="prop_re_write"></marker>
       <tag>{re_write, {Re, Replacement}}</tag>      
       <item>
-	<p>Where Re = string() and Replacement = string(). 
-	The ReWrite property allows documents to be stored in the local file
-	system instead of the document_root location. URLs are rewritten
-        by re:replace/3 to produce a path in the local filesystem.
-        For example:
+	<p><c>Re = string()</c> and <c>Replacement = string()</c>. 
+	<c>re_write</c> allows documents to be stored in the local file
+	system instead of the <c>document_root</c> location. URLs are rewritten
+        by <c>re:replace/3</c> to produce a path in the local file-system,
+        for example:
 	
 	<code>{re_write, {"^/[~]([^/]+)(.*)$", "/home/\\1/public\\2"}}</code>
 	
-	and an access to http://your.server.org/~bob/foo.gif would refer to
+	Access to http://your.server.org/~bob/foo.gif would refer to
 	the file /home/bob/public/foo.gif.
 
-        In an Apache like configuration file the Re is separated
-        from Replacement with one single space, and as expected
-        backslashes do not need to be backslash escaped so the
+        In an Apache-like configuration file, <c>Re</c> is separated
+        from <c>Replacement</c> with one single space, and as expected
+        backslashes do not need to be backslash escaped, the
         same example would become:
 
         <code>ReWrite ^/[~]([^/]+)(.*)$ /home/\1/public\2</code>
 
-        Beware of trailing space in Replacement that will be used.
-        If you must have a space in Re use e.g the character encoding
-        <code>\040</code> see <seealso marker="stdlib:re">re(3)</seealso>. </p>
+        Beware of trailing space in <c>Replacement</c> to be used.
+        If you must have a space in <c>Re</c>, use, for example, the character 
+	encoding <c>\040</c>, see 
+	<seealso marker="stdlib:re">re(3)</seealso>.</p>
       </item>
 
       <marker id="prop_dir_idx"></marker>
       <tag>{directory_index, [string()]}</tag>      
       <item> 
-	<p>DirectoryIndex specifies a list of resources to look for
-	if a client requests a directory using a / at the end of the
-	directory name. file depicts the name of a file in the
-	directory. Several files may be given, in which case the server
-	will return the first it finds, for example:
+	<p><c>directory_index</c> specifies a list of resources to look for
+	if a client requests a directory using a <c>/</c> at the end of the
+	directory name. <c>file</c> depicts the name of a file in the
+	directory. Several files can be given, in which case the server
+	returns the first it finds, for example:
 	
 	<code>{directory_index, ["index.hml", "welcome.html"]}</code>
 	
-	and access to http://your.server.org/docs/ would return
+	Access to http://your.server.org/docs/ would return
 	http://your.server.org/docs/index.html or
-	http://your.server.org/docs/welcome.html if index.html do not
-	exist. </p>
+	http://your.server.org/docs/welcome.html if index.html does not
+	exist.</p>
       </item> 
     </taglist>
 
     <marker id="props_cgi"></marker>
-    <p><em>CGI properties - requires mod_cgi</em></p>
+    <p><em>CGI Properties - Requires mod_cgi</em></p>
     <taglist> 
       <marker id="prop_script_alias"></marker>
       <tag>{script_alias, {Alias, RealName}}</tag>
       <item>
-	<p>Where Alias = string() and RealName = string().
-	Has the same behavior as the Alias property, except that
-	it also marks the target directory as containing CGI
+	<p><c>Alias = string()</c> and <c>RealName = string()</c>.
+	Have the same behavior as property <c>alias</c>, except that
+	they also mark the target directory as containing CGI
 	scripts. URLs with a path beginning with url-path are mapped to
 	scripts beginning with directory-filename, for example:
 	
 	<code>{script_alias, {"/cgi-bin/", "/web/cgi-bin/"}}</code>
 	
-	and an access to http://your.server.org/cgi-bin/foo would cause
-	the server to run the script /web/cgi-bin/foo. </p>
+	Access to http://your.server.org/cgi-bin/foo would cause
+	the server to run the script /web/cgi-bin/foo.</p>
       </item>
       
       <marker id="prop_script_re_write"></marker>
       <tag>{script_re_write, {Re, Replacement}}</tag>
       <item>
-	<p>Where Re = string() and Replacement = string().
-	Has the same behavior as the ReWrite property, except that
-	it also marks the target directory as containing CGI
+	<p><c>Re = string()</c> and <c>Replacement = string()</c>.
+	Have the same behavior as property <c>re_write</c>, except that
+	they also mark the target directory as containing CGI
 	scripts. URLs with a path beginning with url-path are mapped to
 	scripts beginning with directory-filename, for example:
 	
 	<code>{script_re_write, {"^/cgi-bin/(\\d+)/", "/web/\\1/cgi-bin/"}}</code>
 	
-	and an access to http://your.server.org/cgi-bin/17/foo would cause
-	the server to run the script /web/17/cgi-bin/foo. </p>
+	Access to http://your.server.org/cgi-bin/17/foo would cause
+	the server to run the script /web/17/cgi-bin/foo.</p>
       </item>
       
       <marker id="prop_script_nocache"></marker>
       <tag>{script_nocache, boolean()}</tag>
       <item> 
-	<p>If ScriptNoCache is set to true the HTTP server will by
-	default add the header fields necessary to prevent proxies from
-	caching the page. Generally this is something you want. Defaults
-	to false. </p>
+	<p>If <c>script_nocache</c> is set to <c>true</c>, the HTTP server by
+	default adds the header fields necessary to prevent proxies from
+	caching the page. Generally this is preferred. 
+	Default to <c>false</c>.</p>
       </item>
       
       <marker id="prop_script_timeout"></marker>
       <tag>{script_timeout, integer()}</tag>
       <item>
-	<p>The time in seconds the web server will wait between each
-	chunk of data from the script. If the CGI-script not delivers
-	any data before the timeout the connection to the client will be
-	closed. Defaults to 15. </p>
+	<p>The time in seconds the web server waits between each
+	chunk of data from the script. If the CGI script does not deliver
+	any data before the timeout, the connection to the client is
+	closed. Default is <c>15</c>.</p>
       </item>
       
       <marker id="prop_action"></marker>
       <tag>{action, {MimeType, CgiScript}} - requires mod_action</tag>
       <item>
-	<p>Where MimeType = string() and CgiScript = string().
-	Action adds an action, which will activate a cgi-script
-	whenever a file of a certain mime-type is requested. It
+	<p><c>MimeType = string()</c> and <c>CgiScript = string()</c>.
+	<c>action</c> adds an action activating a CGI script
+	whenever a file of a certain MIME type is requested. It
 	propagates the URL and file path of the requested document using
 	the standard CGI PATH_INFO and PATH_TRANSLATED environment
-	variables.
+	variables.</p>
+	<p>Example:</p>
 
 	<code>{action, {"text/plain", "/cgi-bin/log_and_deliver_text"}}</code>
-	</p>
       </item>
 
       <marker id="prop_script"></marker>
       <tag>{script, {Method, CgiScript}} - requires mod_action</tag>
       <item>
-	<p>Where Method = string() and CgiScript = string().
-	Script adds an action, which will activate a cgi-script
+	<p><c>Method = string()</c> and <c>CgiScript = string()</c>.
+	<c>script</c> adds an action activating a CGI script
 	whenever a file is requested using a certain HTTP method. The
-	method is either GET or POST as defined in RFC 1945. It
+	method is either GET or POST, as defined in <url href="http://www.ietf.org/rfc/rfc1945.txt">RFC 1945</url>. It
 	propagates the URL and file path of the requested document using
 	the standard CGI PATH_INFO and PATH_TRANSLATED environment
-	variables.
+	variables.</p>
+	<p>Example:</p>
 	
 	<code>{script, {"PUT", "/cgi-bin/put"}}</code>
-	</p>
 	
       </item>
     </taglist>
     
     <marker id="props_esi"></marker>
-    <p><em>ESI properties - requires mod_esi</em></p>
+    <p><em>ESI Properties - Requires mod_esi</em></p>
     <taglist>
       <marker id="prop_esi_alias"></marker>
       <tag>{erl_script_alias, {URLPath, [AllowedModule]}}</tag>      
       <item>
-	<p>Where URLPath = string() and AllowedModule = atom().
-	erl_script_alias marks all URLs matching url-path as erl
+	<p><c>URLPath = string()</c> and <c>AllowedModule = atom()</c>.
+	<c>erl_script_alias</c> marks all URLs matching url-path as erl
 	scheme scripts. A matching URL is mapped into a specific module
-	and function. For example:
+	and function, for example:
 	
-	<code>{erl_script_alias, {"/cgi-bin/example", [httpd_example]}}
-	</code>
+	<code>{erl_script_alias, {"/cgi-bin/example", [httpd_example]}}</code>
 	
-	and a request to
+	A request to
 	http://your.server.org/cgi-bin/example/httpd_example:yahoo
-	would refer to httpd_example:yahoo/3 or, if that did not exist,
+	would refer to httpd_example:yahoo/3 or, if that does not exist,
 	httpd_example:yahoo/2 and
 	http://your.server.org/cgi-bin/example/other:yahoo would
-	not be allowed to execute. </p>
+	not be allowed to execute.</p>
       </item>
 
       <marker id="prop_esi_nocache"></marker>
       <tag>{erl_script_nocache, boolean()}</tag>
       <item>
-	<p>If erl_script_nocache is set to true the server will add
-	http header fields that prevents proxies from caching the
-	page. This is generally a good idea for dynamic content, since
-	the content often vary between each request. 
-	Defaults to false. </p>
+	<p>If <c>erl_script_nocache</c> is set to <c>true</c>, the server adds
+	HTTP header fields preventing proxies from caching the
+	page. This is generally a good idea for dynamic content, as
+	the content often varies between each request. 
+	Default is <c>false</c>.</p>
       </item>
 
       <marker id="prop_esi_timeout"></marker>
       <tag>{erl_script_timeout, integer()}</tag>
       <item>
-	<p>If erl_script_timeout sets the time in seconds the server will
-	wait between each chunk of data to be delivered through
-	mod_esi:deliver/2. Defaults to 15. This is only relevant
-	for scripts that uses the erl scheme. </p>
+	<p>If <c>erl_script_timeout</c> sets the time in seconds the server
+	waits between each chunk of data to be delivered through
+	<c>mod_esi:deliver/2</c>. Default is <c>15</c>. This is only relevant
+	for scripts that use the erl scheme.</p>
       </item>
 
       <marker id="prop_esi_timeout"></marker>
       <tag>{eval_script_alias, {URLPath, [AllowedModule]}}</tag>
       <item>
-	<p>Where URLPath = string() and AllowedModule = atom().
-	Same as erl_script_alias but for scripts
-	using the eval scheme. Note that this is only supported
-	for backwards compatibility. The eval scheme is deprecated. </p>
+	<p><c>URLPath = string()</c> and <c>AllowedModule = atom()</c>.
+	Same as <c>erl_script_alias</c> but for scripts
+	using the eval scheme. This is only supported
+	for backwards compatibility. The eval scheme is deprecated.</p>
       </item>
     </taglist>
 
     <marker id="props_log"></marker>
-    <p><em>Log properties - requires mod_log</em></p>
+    <p><em>Log Properties - Requires mod_log</em></p>
     <taglist>
       <marker id="prop_elog"></marker>
       <tag>{error_log, path()}</tag>
       <item>
 	<p>Defines the filename of the error log file to be used to log
-	server errors. If the filename does not begin with a slash (/)
-	it is assumed to be relative to the server_root. </p>
+	server errors. If the filename does not begin with a slash (/),
+	it is assumed to be relative to the <c>server_root</c>.</p>
       </item>
 
       <marker id="prop_slog"></marker>
@@ -640,7 +641,7 @@ bytes
       <item>
 	<p>Defines the filename of the access log file to be used to
 	log security events. If the filename does not begin with a slash
-	(/) it is assumed to be relative to the server_root. </p>
+	(/), it is assumed to be relative to the <c>server_root</c>.</p>
       </item>
 
       <marker id="prop_tlog"></marker>
@@ -648,270 +649,270 @@ bytes
       <item> 
 	<p>Defines the filename of the access log file to be used to
 	log incoming requests. If the filename does not begin with a
-	slash (/) it is assumed to be relative to the server_root. </p>
+	slash (/), it is assumed to be relative to the <c>server_root</c>.</p>
       </item>
     </taglist>
 
     <marker id="props_dlog"></marker>
-    <p><em>Disk Log properties - requires mod_disk_log</em></p>
+    <p><em>Disk Log Properties - Requires mod_disk_log</em></p>
     <taglist>
       <marker id="prop_dlog_format"></marker>
       <tag>{disk_log_format, internal | external}</tag>
       <item>
-	<p>Defines the file-format of the log files see disk_log for
-	more information. If the internal file-format is used, the
-	logfile will be repaired after a crash. When a log file is
-	repaired data might get lost. When the external file-format is
-	used httpd will not start if the log file is broken. Defaults to
-	external. </p>
+	<p>Defines the file format of the log files. See <c>disk_log</c> for
+	details. If the internal file format is used, the
+	log file is repaired after a crash. When a log file is
+	repaired, data can disappear. When the external file format is
+	used, <c>httpd</c> does not start if the log file is broken. Default is
+	<c>external</c>.</p>
       </item>
 
       <marker id="prop_edlog"></marker>
       <tag>{error_disk_log, path()}</tag>
       <item>
-	<p>Defines the filename of the (disk_log(3)) error log file
+	<p>Defines the filename of the (<c>disk_log(3)</c>) error log file
 	to be used to log server errors. If the filename does not begin
-	with a slash (/) it is assumed to be relative to the server_root. </p>
+	with a slash (/), it is assumed to be relative to the <c>server_root</c>.</p>
       </item>
 
       <marker id="prop_edlog_size"></marker>
       <tag>{error_disk_log_size, {MaxBytes, MaxFiles}}</tag>
       <item>
-	<p>Where MaxBytes = integer() and MaxFiles = integer().
-	Defines the properties of the (disk_log(3)) error log
-	file. The disk_log(3) error log file is of type wrap log and
-	max-bytes will be written to each file and max-files will be
-	used before the first file is truncated and reused. </p>
+	<p><c>MaxBytes = integer()</c> and <c>MaxFiles = integer()</c>.
+	Defines the properties of the (<c>disk_log(3)</c>) error log
+	file. This file is of type wrap log and
+	max bytes is written to each file and max files is
+	used before the first file is truncated and reused.</p>
       </item>
 
       <marker id="prop_sdlog"></marker>
       <tag>{security_disk_log, path()}</tag>
       <item>
-	<p>Defines the filename of the (disk_log(3)) access log file
-	which logs incoming security events i.e authenticated
-	requests. If the filename does not begin with a slash (/) it
-	is assumed to be relative to the server_root. </p>
+	<p>Defines the filename of the (<c>disk_log(3)</c>) access log file
+	logging incoming security events, that is, authenticated
+	requests. If the filename does not begin with a slash (/), it
+	is assumed to be relative to the <c>server_root</c>.</p>
       </item>
 
       <marker id="prop_sdlog_size"></marker>
       <tag>{security_disk_log_size, {MaxBytes, MaxFiles}}</tag>
       <item>
-	<p>Where MaxBytes = integer() and MaxFiles = integer(). 
-	Defines the properties of the disk_log(3) access log
-	file. The disk_log(3) access log file is of type wrap log and
-	max-bytes will be written to each file and max-files will be
-	used before the first file is truncated and reused. </p>
+	<p><c>MaxBytes = integer()</c> and <c>MaxFiles = integer()</c>. 
+	Defines the properties of the <c>disk_log(3)</c> access log
+	file. This file is of type wrap log and
+	max bytes is written to each file and max files is
+	used before the first file is truncated and reused.</p>
       </item>
 
       <marker id="prop_tdlog"></marker>
       <tag>{transfer_disk_log, path()}</tag> 
       <item>
-	<p>Defines the filename of the (disk_log(3)) access log file
-	which logs incoming requests. If the filename does not begin
-	with a slash (/) it is assumed to be relative to the
-	server_root. </p>
+	<p>Defines the filename of the (<c>disk_log(3)</c>) access log file
+	logging incoming requests. If the filename does not begin
+	with a slash (/), it is assumed to be relative to the
+	<c>server_root</c>.</p>
       </item>
       
       <marker id="prop_tdlog_size"></marker>
       <tag>{transfer_disk_log_size, {MaxBytes, MaxFiles}}</tag>
       <item>
-	<p>Where MaxBytes = integer() and MaxFiles = integer().  
-	Defines the properties of the disk_log(3) access log
-	file. The disk_log(3) access log file is of type wrap log and
-	max-bytes will be written to each file and max-files will be
-	used before the first file is truncated and reused. </p>
+	<p><c>MaxBytes = integer()</c> and <c>MaxFiles = integer()</c>.  
+	Defines the properties of the <c>disk_log(3)</c> access log
+	file. This file is of type wrap log and
+	max bytes is written to each file and max files is
+	used before the first file is truncated and reused.</p>
       </item>
     </taglist>
 
     <marker id="props_auth"></marker>
-    <p><em>Authentication properties - requires mod_auth</em></p>
+    <p><em>Authentication Properties - Requires mod_auth</em></p>
 
     <marker id="prop_dri"></marker>
     <p><em>{directory, {path(), [{property(), term()}]}}</em></p>
 
     <marker id="props_dir"></marker>
-    <p>Here follows the valid properties for directories </p>
+    <p>The properties for directories are as follows:</p>
     
     <taglist>
       <marker id="prop_allow_from"></marker>
-      <tag>{allow_from,  all | [RegxpHostString]}</tag>
+      <tag>{allow_from, all | [RegxpHostString]}</tag>
       <item>
-	<p>Defines a set of hosts which should be granted access to a
-	given directory.
-	
-	For example:
+	<p>Defines a set of hosts to be granted access to a
+	given directory, for example:
 	
 	<code>{allow_from, ["123.34.56.11", "150.100.23"]}</code>
           
-	The host 123.34.56.11 and all machines on the 150.100.23
-	subnet are allowed access. </p>
+	The host <c>123.34.56.11</c> and all machines on the <c>150.100.23</c>
+	subnet are allowed access.</p>
       </item>
       
       <marker id="prop_deny_from"></marker>
-      <tag>{deny_from,  all | [RegxpHostString]}</tag>
+      <tag>{deny_from, all | [RegxpHostString]}</tag>
       <item>
 	<p>Defines a set of hosts
-	which should be denied access to a given directory.
-	For example:
+	to be denied access to a given directory, for example:
 	
 	<code>{deny_from, ["123.34.56.11", "150.100.23"]}</code>
           
-	The host 123.34.56.11 and all machines on the 150.100.23
-	subnet are not allowed access. </p>
+	The host <c>123.34.56.11</c> and all machines on the <c>150.100.23</c>
+	subnet are not allowed access.</p>
       </item>
 
       <marker id="prop_auth_type"></marker>
-      <tag>{auth_type,  plain | dets | mnesia}</tag>
+      <tag>{auth_type, plain | dets | mnesia}</tag>
       <item>
 	<p>Sets the type of authentication database that is used for the
-	directory.The key difference between the different methods is
-	that dynamic data can be saved when Mnesia and Dets is used.
-	This property is called AuthDbType in the Apache like
-	configuration files. </p>
+	directory. The key difference between the different methods is
+	that dynamic data can be saved when <c>Mnesia</c> and <c>Dets</c> 
+	are used.
+	This property is called <c>AuthDbType</c> in the Apache-like
+	configuration files.</p>
       </item>
 
       <marker id="prop_auth_user_file"></marker>
       <tag>{auth_user_file, path()}</tag>
       <item>
-	<p>Sets the name of a file which contains the list of users and
-	passwords for user authentication. filename can be either
+	<p>Sets the name of a file containing the list of users and
+	passwords for user authentication. The filename can be either
 	absolute or relative to the <c>server_root</c>. If using the
-	plain storage method, this file is a plain text file, where
-	each line contains a user name followed by a colon, followed
-	by the non-encrypted password. If user names are duplicated,
-	the behavior is undefined. For example:
+	plain storage method, this file is a plain text file where
+	each line contains a username followed by a colon, followed
+	by the non-encrypted password. If usernames are duplicated,
+	the behavior is undefined.</p>
+	<p>Example:</p>
 	
 	<code> ragnar:s7Xxv7
  edward:wwjau8 </code> 
 
-	If using the dets storage method, the user database is
-	maintained by dets and should not be edited by hand. Use the
-	API functions in mod_auth module to create / edit the user
-	database.  This directive is ignored if using the mnesia
-	storage method.  For security reasons, make sure that the
-	<c>auth_user_file</c> is stored outside the document tree of the Web
-	server. If it is placed in the directory which it protects,
-	clients will be able to download it. </p>
+	<p>If the <c>Dets</c> storage method is used, the user database is
+	maintained by <c>Dets</c> and must not be edited by hand. Use the
+	API functions in module <c>mod_auth</c> to create/edit the user
+	database. This directive is ignored if the <c>Mnesia</c>
+	storage method is used. For security reasons, ensure that
+	<c>auth_user_file</c> is stored outside the document tree of the web
+	server. If it is placed in the directory that it protects,
+	clients can download it.</p>
       </item>
       
       <marker id="prop_auth_group_file"></marker>
       <tag>{auth_group_file, path()}</tag>
       <item>
-	<p>Sets the name of a file which contains the list of user
-	groups for user authentication. Filename can be either
-	absolute or relative to the <c>server_root</c>.  If you use the plain
-	storage method, the group file is a plain text file, where
+	<p>Sets the name of a file containing the list of user
+	groups for user authentication. The filename can be either
+	absolute or relative to the <c>server_root</c>. If the plain
+	storage method is used, the group file is a plain text file, where
 	each line contains a group name followed by a colon, followed
-	by the member user names separated by spaces. For example:
+	by the members usernames separated by spaces.</p>
+	<p>Example:</p>
 	
 	<code>group1: bob joe ante</code>
           
-	If using the dets storage method, the group database is
-	maintained by dets and should not be edited by hand. Use the
-	API for mod_auth module to create / edit the group database.
-	This directive is ignored if using the mnesia storage method.
-	For security reasons, make sure that the <c>auth_group_file</c> is
-	stored outside the document tree of the Web server. If it is
-	placed in the directory which it protects, clients will be
-	able to download it. </p>
+	<p>If the <c>Dets</c> storage method is used, the group database is
+	maintained by <c>Dets</c> and must not be edited by hand. Use the
+	API for module <c>mod_auth</c> to create/edit the group database.
+	This directive is ignored if the <c>Mnesia</c> storage method is used.
+	For security reasons, ensure that the <c>auth_group_file</c> is
+	stored outside the document tree of the web server. If it is
+	placed in the directory that it protects, clients
+	can download it.</p>
       </item>
 
       <marker id="prop_auth_name"></marker>
       <tag>{auth_name, string()}</tag>
       <item> 
 	<p>Sets the name of the authorization realm (auth-domain) for
-	a directory. This string informs the client about which user
-	name and password to use. </p>
+	a directory. This string informs the client about which 
+	username and password to use.</p>
       </item>
 
       <marker id="prop_auth_access_passwd"></marker>
       <tag>{auth_access_password, string()}</tag>
       <item>
-	<p>If set to other than "NoPassword" the password is required
-	for all API calls. If the password is set to "DummyPassword" the
+	<p>If set to other than "NoPassword", the password is required
+	for all API calls. If the password is set to "DummyPassword", the
 	password must be changed before any other API calls. To secure
-	the authenticating data the password must be changed after the
-	web server is started since it otherwise is written in clear
-	text in the configuration file. </p>
+	the authenticating data, the password must be changed after the
+	web server is started. Otherwise it is written in clear
+	text in the configuration file.</p>
       </item>
       
       <marker id="prop_req_user"></marker>
       <tag>{require_user, [string()]}</tag>
       <item> 
-	<p>Defines users which should be granted access to a given
-	directory using a secret password. </p>
+	<p>Defines users to grant access to a given
+	directory using a secret password.</p>
       </item>
 
       <marker id="prop_req_grp"></marker>
       <tag>{require_group, [string()]}</tag>
       <item>
-	<p>Defines users which should be granted access to a given
-	directory using a secret password. </p>
+	<p>Defines users to grant access to a given
+	directory using a secret password.</p>
       </item>
       
     </taglist>
 
     <marker id="props_htaccess"></marker> 
-    <p><em>Htaccess authentication properties - requires mod_htaccess</em></p>
+    <p><em>Htaccess Authentication Properties - Requires mod_htaccess</em></p>
     <taglist>
       <marker id="prop_access_files"></marker>
       <tag>{access_files, [path()]}</tag>
       <item>
-	<p>Specify which filenames that are used for
-	access-files. When a request comes every directory in the path
-	to the requested asset will be searched after files with the
-	names specified by this parameter. If such a file is found the
-	file will be parsed and the restrictions specified in it will
-	be applied to the request. </p>
+	<p>Specifies the filenames that are used for
+	access files. When a request comes, every directory in the path
+	to the requested asset are searched after files with the
+	names specified by this parameter. If such a file is found, the
+	file is parsed and the restrictions specified in it are
+	applied to the request.</p>
       </item>
     </taglist>
 
     <marker id="props_sec"></marker>
-    <p><em>Security properties - requires mod_security </em></p>
+    <p><em>Security Properties - Requires mod_security</em></p>
  
     <marker id="prop_sec_dir"></marker>
     <p><em>{security_directory, {path(), [{property(), term()}]}}</em></p>
        
     <marker id="props_sdir"></marker>
-    <p>Here follows the valid properties for security directories</p>
+    <p>The properties for the security directories are as follows:</p>
     <taglist>
       <marker id="prop_data_file"></marker>
       <tag>{data_file, path()}</tag>      
       <item>
-	<p>Name of the security data file.  The filename can either
-	absolute or relative to the server_root. This file is used to
-	store persistent data for the mod_security module. </p>
+	<p>Name of the security data file. The filename can either be
+	absolute or relative to the <c>server_root</c>. This file is used to
+	store persistent data for module <c>mod_security</c>.</p>
       </item>
 	  
       <marker id="prop_max_retries"></marker>
       <tag>{max_retries, integer()}</tag>	  
       <item>
-	<p>Specifies the maximum number of tries to authenticate a
-	user has before the user is blocked out. If a user
-	successfully authenticates when the user has been blocked, the
-	user will receive a 403 (Forbidden) response from the
-	server. If the user makes a failed attempt while blocked the
-	server will return 401 (Unauthorized), for security
+	<p>Specifies the maximum number of attempts to authenticate a
+	user before the user is blocked out. If a user
+	successfully authenticates while blocked, the
+	user receives a 403 (Forbidden) response from the
+	server. If the user makes a failed attempt while blocked, the
+	server returns 401 (Unauthorized), for security
 	reasons. 
-	Defaults to 3 may also be set to infinity. </p>
+	Default is <c>3</c>. Can be set to infinity.</p>
       </item>
 	
       <marker id="prop_block_time"></marker>
       <tag>{block_time, integer()}</tag>
       <item>
 	<p>Specifies the number of minutes a user is blocked. After
-	this amount of time, he automatically regains access.
-	Defaults to 60. </p>
+	this timehas passed, the user automatically regains access.
+	Default is <c>60</c>.</p>
       </item>
       
       <marker id="prop_fail_exp_time"></marker>
       <tag>{fail_expire_time, integer()}</tag>
       <item>
 	<p>Specifies the number of minutes a failed user authentication
-	is remembered. If a user authenticates after this amount of
-	time, his previous failed authentications are
+	is remembered. If a user authenticates after this
+	time has passed, the previous failed authentications are
 	forgotten. 
-	Defaults to 30. </p>
+	Default is <c>30</c>.</p>
       </item>
       
       <marker id="prop_auth_timeout"></marker>
@@ -919,43 +920,43 @@ bytes
       <item>
 	Specifies the number of seconds a successful user
 	authentication is remembered. After this time has passed, the
-	authentication will no longer be reported. Defaults to 30.
+	authentication is no longer reported. Default is <c>30</c>.
       </item>
     </taglist>    
   </section>
 
   <funcs>
     <func>
-      <marker id="info1"></marker>
       <name>info(Pid) -></name>
       <name>info(Pid, Properties) -> [{Option, Value}]</name>
-      <fsummary>Fetches information about the HTTP server</fsummary>
+      <fsummary>Fetches information about the HTTP server.</fsummary>
       <type>
         <v>Properties = [property()]</v>
-	<v>Option =  property()</v>
+	<v>Option = property()</v>
 	<v>Value = term()</v>
       </type>
       <desc>
         <p>Fetches information about the HTTP server. When called
-	with only the pid all properties are fetched, when called
-	with a list of specific properties they are fetched.
-	Available properties are the same as the server's start options. 
+	with only the pid, all properties are fetched. When called
+	with a list of specific properties, they are fetched.
+	The available properties are the same as the start options
+	of the server. 
 	</p>
 	
-	<note><p>Pid is the pid returned from inets:start/[2,3]. 
-	    Can also be retrieved form inets:services/0, inets:services_info/0
-	    see <seealso marker="inets">inets(3)</seealso>
+	<note><p>Pid is the pid returned from <c>inets:start/[2,3]</c>. 
+	    Can also be retrieved form <c>inets:services/0</c> and
+	    <c>inets:services_info/0</c>,
+	    see <seealso marker="inets">inets(3)</seealso>.
 	  </p></note>
       </desc>
     </func>
 
     <func>
-      <marker id="info2"></marker>
       <name>info(Address, Port) ->  </name>
       <name>info(Address, Port, Profile) ->  </name>
       <name>info(Address, Port, Profile, Properties) -> [{Option, Value}] </name>
       <name>info(Address, Port, Properties) -> [{Option, Value}] </name>
-      <fsummary>Fetches information about the HTTP server</fsummary>
+      <fsummary>Fetches information about the HTTP server.</fsummary>
       <type>
 	<v>Address = ip_address()</v>
 	<v>Port = integer()</v>
@@ -966,20 +967,19 @@ bytes
       </type>
       <desc>
         <p>Fetches information about the HTTP server. When called with
-	only the Address, Port and Profile, if relevant, all properties are fetched.
-	When called with a list of specific properties they are fetched.
-	Available properties are the same as the server's start
-	options.
+        only <c>Address</c> and <c>Port</c>, all properties are
+        fetched.  When called with a list of specific properties, they
+        are fetched.  The available properties are the same as the
+        start options of the server.
 	</p>
 
-	<note><p> Address has to be the ip-address and can not be
+	<note><p>The address must be the IP address and cannot be
 	    the hostname.
 	  </p></note>	
       </desc>
     </func>
     
     <func>
-      <marker id="reload_config"></marker>
       <name>reload_config(Config, Mode) -> ok | {error, Reason}</name>
       <fsummary>Reloads the HTTP server configuration without
 	restarting the server.</fsummary>
@@ -991,24 +991,26 @@ bytes
       </type>
       <desc>
 	<p>Reloads the HTTP server configuration without restarting the
-	  server. Incoming requests will be answered with a temporary
-	  down message during the time the it takes to reload.</p>
+	  server. Incoming requests are answered with a temporary
+	  down message during the reload time.</p>
 	
-	<note><p>Available properties are the same as the server's
-	    start options, although the properties bind_address and
-	    port can not be changed.</p></note>
+	<note><p>Available properties are the same as the
+	    start options of the server, but the properties 
+	    <c>bind_address</c> and <c>port</c> 
+	    cannot be changed.</p></note>
 	
-	<p>If mode is disturbing, the server is blocked forcefully and
-	  all ongoing requests are terminated and the reload will
-	  start immediately. If mode is non-disturbing, no new
-	  connections are accepted, but the ongoing requests are
+	<p>If mode is disturbing, the server is blocked forcefully,
+	  all ongoing requests terminates, and the reload
+	  starts immediately. If mode is non-disturbing, no new
+	  connections are accepted, but ongoing requests are
 	  allowed to complete before the reload is done.</p>
       </desc>
     </func>
   </funcs>
 
   <section>
-    <title>ERLANG WEB SERVER API DATA TYPES </title>
+    <title>ERLANG WEB SERVER API DATA TYPES</title>
+    <p>The Erlang web server API data types are as follows:</p>
     <code type="none">
       ModData = #mod{}
 
@@ -1025,73 +1027,75 @@ bytes
 		parsed_header = [],
 		entity_body,
 		connection
-	}).
-    </code>
+	}).</code>
 
-    <p>To acess the record in your callback-module use </p>
-    <code> -include_lib("inets/include/httpd.hrl"). </code>
+    <p>To acess the record in your callback-module use:</p>
+    <code> -include_lib("inets/include/httpd.hrl").</code>
 
-    <p>The fields of the <c>mod</c> record has the following meaning:
+    <p>The fields of record <c>mod</c> have the following meaning:
       </p>
     <taglist>
       <tag><c>data</c></tag>
-      <item>Type <c>[{InteractionKey,InteractionValue}]</c> is used to
+      <item><p>Type <c>[{InteractionKey,InteractionValue}]</c> is used to
        propagate data between modules. Depicted
-      <c>interaction_data()</c> in function type declarations.
+      <c>interaction_data()</c> in function type declarations.</p>
       </item>
       <tag><c>socket_type</c></tag>
-      <item><c>socket_type()</c>,
-       Indicates whether it is an ip  socket or a  ssl socket.
+      <item><p><c>socket_type()</c>
+       indicates whether it is an IP socket or an <c>ssl</c> socket.</p>
       </item>
       <tag><c>socket</c></tag>
-      <item>The actual socket in <c>ip_comm</c> or <c>ssl</c> format
-       depending on the <c>socket_type</c>.
+      <item><p>The socket, in format <c>ip_comm</c> or <c>ssl</c>,
+       depending on <c>socket_type</c>.</p>
       </item>
       <tag><c>config_db</c></tag>
-      <item>The config file directives stored as key-value tuples in
-       an ETS-table. Depicted <c>config_db()</c> in function type
-       declarations.
+      <item><p>The config file directives stored as key-value tuples in
+       an ETS table. Depicted <c>config_db()</c> in function type
+       declarations.</p>
       </item>
       <tag><c>method</c></tag>
-      <item>Type <c>"GET" | "POST" | "HEAD" | "TRACE"</c>, that is the
-       HTTP method.
+      <item><p>Type <c>"GET" | "POST" | "HEAD" | "TRACE"</c>, that is, the
+       HTTP method.</p>
       </item>
       <tag><c>absolute_uri</c></tag>
-      <item>If the request is a HTTP/1.1
-       request the URI might be in the absolute URI format.  In that
-       case httpd will save the absolute URI in this field.  An Example
-       of an absolute URI could
-       be<c>"http://ServerName:Part/cgi-bin/find.pl?person=jocke"</c></item>
+      <item><p>If the request is an HTTP/1.1
+       request, the URI can be in the absolute URI format. In that
+       case, <c>httpd</c> saves the absolute URI in this field. An Example
+       of an absolute URI is 
+      <c>"http://ServerName:Part/cgi-bin/find.pl?person=jocke"</c></p></item>
       <tag><c>request_uri</c></tag>
-      <item>The <c>Request-URI</c> as defined
-       in RFC 1945, for example <c>"/cgi-bin/find.pl?person=jocke"</c></item>
+      <item><p>The <c>Request-URI</c> as defined
+       in <url href="http://www.ietf.org/rfc/rfc1945.txt">RFC 1945</url>, for example, <c>"/cgi-bin/find.pl?person=jocke"</c>.</p>
+      </item>
       <tag><c>http_version</c></tag>
-      <item>The <c>HTTP</c> version of the
-       request, that is "HTTP/0.9", "HTTP/1.0", or "HTTP/1.1".
+      <item><p>The <c>HTTP</c> version of the
+       request, that is, "HTTP/0.9", "HTTP/1.0", or "HTTP/1.1".</p>
       </item>
       <tag><c>request_line</c></tag>
-      <item>The <c>Request-Line</c> as
-       defined in RFC 1945, for example <c>"GET /cgi-bin/find.pl?person=jocke HTTP/1.0"</c>.
+      <item><p>The <c>Request-Line</c> as
+       defined in<url href="http://www.ietf.org/rfc/rfc1945.txt">RFC 1945</url>, for example, 
+       <c>"GET /cgi-bin/find.pl?person=jocke HTTP/1.0"</c>.</p>
       </item>
       <tag><c>parsed_header</c></tag>
-      <item>Type <c>[{HeaderKey,HeaderValue}]</c>,
+      <item>Type <c>[{HeaderKey,HeaderValue}]</c>.
       <c>parsed_header</c> contains all HTTP header fields from the
-      HTTP-request stored in a list as key-value tuples. See RFC 2616
-      for a listing of all header fields. For example the date field
-      would be stored as: <c>{"date","Wed, 15 Oct 1997 14:35:17 GMT"} </c>.
-      RFC 2616 defines that HTTP is a case insensitive protocol and
-      the header fields may be in lower case or upper case. Httpd will
-      ensure that all header field names are in lower case.
+      HTTP request stored in a list as key-value tuples. See
+      <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>
+      for a listing of all header fields. For example, the date field
+      is stored as <c>{"date","Wed, 15 Oct 1997 14:35:17 GMT"}</c>.
+      RFC 2616 defines that HTTP is a case-insensitive protocol and
+      the header fields can be in lower case or upper case. <c>httpd</c>
+      ensures that all header field names are in lower case.
       </item>
       <tag><c>entity_body</c></tag>
-      <item>The <c>Entity-Body</c> as defined
-       in RFC 2616, for example data sent from a CGI-script using the
-       POST method.
+      <item><p>The <c>entity-Body</c> as defined
+       in <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>, for example, data sent from a CGI script using the
+       POST method.</p>
       </item>
       <tag><c>connection</c></tag>
-      <item><c>true | false</c> If set to true the connection to the
-       client is a persistent connection and will not be closed when
-       the request is served.</item>
+      <item><p><c>true | false</c>. If set to <c>true</c>, the connection to the
+       client is a persistent connection and is not closed when
+       the request is served.</p></item>
     </taglist>
   </section>
 
@@ -1100,56 +1104,63 @@ bytes
   </section>
   <funcs>
     <func>
-      <marker id="module_do"></marker>
       <name>Module:do(ModData)-> {proceed, OldData} | {proceed, NewData} | {break, NewData} | done</name>
-      <fsummary>Called for each request to the Web server.</fsummary>
+      <fsummary>Called for each request to the web server.</fsummary>
       <type>
         <v>OldData = list()</v>
-        <v>NewData = [{response,{StatusCode,Body}}] | [{response,{response,Head,Body}}] |  [{response,{already_sent,Statuscode,Size}}] </v>
+        <v>NewData = [{response,{StatusCode,Body}}]</v>
+	<v>| [{response,{response,Head,Body}}]</v>
+	<v>| [{response,{already_sent,Statuscode,Size}}]</v>
         <v>StatusCode = integer()</v>
         <v>Body = io_list() | nobody | {Fun, Arg}</v>
         <v>Head = [HeaderOption]</v>
         <v>HeaderOption = {Option, Value} | {code, StatusCode}</v>
-        <v>Option =  accept_ranges | allow | cache_control | content_MD5 | content_encoding | content_language | content_length | content_location | content_range | content_type | date | etag | expires | last_modified | location | pragma | retry_after | server | trailer | transfer_encoding</v>
+        <v>Option = accept_ranges | allow</v>
+	<v>| cache_control | content_MD5</v>
+	<v>| content_encoding | content_language</v>
+	<v>| content_length | content_location</v>
+	<v>| content_range | content_type | date</v>
+	<v>| etag | expires | last_modified</v>
+	<v>| location | pragma | retry_after</v>
+	<v>| server | trailer | transfer_encoding</v>
         <v>Value = string()</v>
         <v>Fun = fun( Arg ) -> sent| close | Body </v>
         <v>Arg = [term()]</v>
       </type>
       <desc>
-        <p>When a valid request reaches httpd it calls <c>do/1</c> in
-          each module defined by the Modules configuration
-          option. The function may generate data for other modules
-          or a response that can be sent back to the client.</p>
-        <p>The field <c>data</c> in ModData is a list. This list will be
+        <p>When a valid request reaches <c>httpd</c>, it calls <c>do/1</c> in
+          each module, defined by the configuration
+          option of <c>Module</c>. The function can generate data for other
+	  modules or a response that can be sent back to the client.</p>
+        <p>The field <c>data</c> in <c>ModData</c> is a list. This list is
           the list returned from the last call to
           <c>do/1</c>.</p>
-        <p><c>Body</c> is the body of the http-response that will be
-          sent back to the client an appropriate header will be
-          appended to the message. <c>StatusCode</c> will be the
-          status code of the response see RFC2616 for the appropriate
-          values.</p>
+        <p><c>Body</c> is the body of the HTTP response that is
+          sent back to the client. An appropriate header is
+          appended to the message. <c>StatusCode</c> is the
+          status code of the response, see 
+	  <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url> 
+	  for the appropriate values.</p>
         <p><c>Head</c> is a key value list of HTTP header fields. The
-          server will construct a HTTP header from this data. See RFC
-          2616 for the appropriate value for each header field. If the
-          client is a HTTP/1.0 client then the server will filter the
-          list so that only HTTP/1.0 header fields will be sent back
-          to the client.</p>
+        server constructs an HTTP header from this data. See <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>  for the appropriate value for each header field. If the
+        client is an HTTP/1.0 client, the server filters the
+        list so that only HTTP/1.0 header fields are sent back
+        to the client.</p>
         <p>If <c>Body</c> is returned and equal to <c>{Fun,Arg}</c>,
-          the Web server will try <c>apply/2</c> on <c>Fun</c> with
-          <c>Arg</c> as argument and expect that the fun either
-          returns a list <c>(Body)</c> that is a HTTP-repsonse or the
-          atom sent if the HTTP-response is sent back to the
-          client. If close is returned from the fun something has gone
-          wrong and the server will signal this to the client by
+          the web server tries <c>apply/2</c> on <c>Fun</c> with
+          <c>Arg</c> as argument. The web server expects that the fun either
+          returns a list <c>(Body)</c> that is an HTTP repsonse, or the
+          atom <c>sent</c> if the HTTP response is sent back to the
+          client. If <c>close</c> is returned from the fun, something has gone
+          wrong and the server signals this to the client by
           closing the connection.</p>
       </desc>
     </func>
 
     <func>
-      <marker id="module_load"></marker>
-      <name>Module:load(Line, AccIn)-> eof | ok | {ok, AccOut} |  {ok, AccOut, {Option, Value}} | {ok, AccOut, [{Option, Value}]} | {error, Reason}  </name>
-      <fsummary>Load is used to convert a line in a Apache like config 
-	file to a <c>{Option, Value}</c> tuple.</fsummary>
+      <name>Module:load(Line, AccIn)-> eof | ok | {ok, AccOut} | {ok, AccOut, {Option, Value}} | {ok, AccOut, [{Option, Value}]} | {error, Reason}</name>
+      <fsummary>Converts a line in an Apache-like config 
+	file to an <c>{Option, Value}</c> tuple.</fsummary>
       <type>
         <v>Line = string()</v>
         <v>AccIn = [{Option, Value}]</v>
@@ -1159,55 +1170,53 @@ bytes
         <v>Reason = term()</v>
       </type>
       <desc>
-	<p>Load is used to convert a line in a Apache like
-	  configuration file to a <c>{Option, Value}</c> tuple.  Some
-	  more complex configuration options such as <c>directory</c>
-	  and <c>security_directory</c> will create an
-	  accumulator.This function does only need clauses for the
+	<p>Converts a line in an Apache-like
+	  configuration file to an <c>{Option, Value}</c> tuple. Some
+	  more complex configuration options, such as <c>directory</c>
+	  and <c>security_directory</c>, create an
+	  accumulator. This function only needs clauses for the
 	  options implemented by this particular callback module.
 	</p>
       </desc>
     </func>
-
+    
     <func>
-      <marker id="module_store"></marker>
-      <name>Module:store({Option, Value}, Config)-> {ok, {Option, NewValue}} | {error, Reason}  </name>
-      <fsummary></fsummary>
+      <name>Module:remove(ConfigDB) -> ok | {error, Reason} </name>
+      <fsummary>Callback function that is called when the web server is closed.</fsummary>
+      <type>
+        <v>ConfigDB = ets_table()</v>
+        <v>Reason = term()</v>
+      </type>
+      <desc>
+        <p>When <c>httpd</c> is shut down, it tries to execute
+          <c>remove/1</c> in each Erlang web server callback module. The
+          programmer can use this function to clean up resources
+          created in the store function.</p>
+      </desc>
+    </func>
+    
+    <func>
+      <name>Module:store({Option, Value}, Config)-> {ok, {Option, NewValue}} | {error, Reason}</name>
+      <fsummary>Checks the validity of the configuration options.</fsummary>
       <type>
         <v>Line = string()</v>
         <v>Option = property()</v>
 	<v>Config = [{Option, Value}]</v>
-        <v>Value = term() </v>
+        <v>Value = term()</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-	<p>This function is used to check the validity of the
+	<p>Checks the validity of the
 	  configuration options before saving them in the internal
-	  database. This function may also have a side effect
-	  e.i. setup necessary extra resources implied by the
+	  database. This function can also have a side effect,
+	  that is, setup of necessary extra resources implied by the
 	  configuration option. It can also
 	  resolve possible dependencies among
 	  configuration options by changing the value of the option.
-	  This function does only need clauses for the options
+	  This function only needs clauses for the options
 	  implemented by this particular callback module.</p>
       </desc>
     </func>
-
-    <func>
-      <marker id="module_remove"></marker>
-      <name>Module:remove(ConfigDB) -> ok | {error, Reason}  </name>
-      <fsummary>Callback function that is called when the Web server is closed.</fsummary>
-      <type>
-        <v>ConfigDB = ets_table()</v>
-        <v>Reason = term()</v>
-      </type>
-      <desc>
-        <p>When httpd is shutdown it will try to execute
-          <c>remove/1</c> in each Erlang web server callback module. The
-          programmer may use this function to clean up resources
-          that may have been created in the store function.</p>
-      </desc>
-    </func>
   </funcs>
 
   <section>
@@ -1215,9 +1224,8 @@ bytes
   </section>
   <funcs>
     <func>
-      <marker id="parse_query"></marker>
-      <name>parse_query(QueryString) ->  [{Key,Value}]</name>
-      <fsummary>Parse incoming data to <c>erl </c>and <c>eval </c>scripts.</fsummary>
+      <name>parse_query(QueryString) -> [{Key,Value}]</name>
+      <fsummary>Parses incoming data to <c>erl</c> and <c>eval</c> scripts.</fsummary>
       <type>
         <v>QueryString = string()</v>
 	<v>Key = string()</v>
@@ -1225,8 +1233,9 @@ bytes
       </type>
       <desc>
         <p><c>parse_query/1</c> parses incoming data to <c>erl</c> and
-          <c>eval</c> scripts (See <seealso marker="mod_esi">mod_esi(3)</seealso>) as defined in the standard
-          URL format, that is '+' becomes 'space' and decoding of
+          <c>eval</c> scripts (see <seealso marker="mod_esi">mod_esi(3)</seealso>) 
+	  as defined in the standard
+          URL format, that is, '+' becomes 'space' and decoding of
           hexadecimal characters (<c>%xx</c>).</p>
       </desc>
     </func>
@@ -1234,8 +1243,9 @@ bytes
 
   <section>
     <title>SEE ALSO</title>
-    <p>RFC 2616, <seealso marker="inets">inets(3)</seealso>,
-      <seealso marker="ssl:ssl">ssl(3)</seealso>
+    <p><url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>, 
+    <seealso marker="inets">inets(3)</seealso>,
+    <seealso marker="ssl:ssl">ssl(3)</seealso>
     </p>
   </section>
 
diff --git a/lib/inets/doc/src/httpd_conf.xml b/lib/inets/doc/src/httpd_conf.xml
deleted file mode 100644
index 54a5885eb4..0000000000
--- a/lib/inets/doc/src/httpd_conf.xml
+++ /dev/null
@@ -1,163 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1997</year><year>2013</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>httpd_conf</title>
-    <prepared>Joakim Greben&ouml;</prepared>
-    <docno></docno>
-    <date>1997-10-14</date>
-    <rev>2.2</rev>
-    <file>httpd_conf.sgml</file>
-  </header>
-  <module>httpd_conf</module>
-  <modulesummary>Configuration utility functions to be used by the Erlang
-    Web server API programmer.</modulesummary>
-  <description>
-    <p>This module provides the Erlang Webserver API programmer with
-    utility functions for adding run-time configuration directives.</p>
-
-    <marker id="check_enum"></marker>
-  </description>
-
-  <funcs>
-    <func>
-      <name>check_enum(EnumString, ValidEnumStrings) -> Result</name>
-      <fsummary>Check if string is a valid enumeration.</fsummary>
-      <type>
-        <v>EnumString = string()</v>
-        <v>ValidEnumStrings = [string()]</v>
-        <v>Result = {ok,atom()} | {error,not_valid}</v>
-      </type>
-      <desc>
-        <marker id="check_enum"></marker>
-        <p><c>check_enum/2</c> checks if <c>EnumString</c> is a valid
-	enumeration of <c>ValidEnumStrings</c> in which case it is
-	returned as an atom.</p>
-
-	<marker id="clean"></marker>
-      </desc>
-    </func>
-
-    <func>
-      <name>clean(String) -> Stripped</name>
-      <fsummary>Remove leading and/or trailing white spaces.</fsummary>
-      <type>
-        <v>String = Stripped = string()</v>
-      </type>
-      <desc>
-        <marker id="clean"></marker>
-        <p><c>clean/1</c> removes leading and/or trailing white spaces
-	from <c>String</c>.</p>
-
-	<marker id="custom_clean"></marker>
-      </desc>
-    </func>
-
-    <func>
-      <name>custom_clean(String,Before,After) -> Stripped</name>
-      <fsummary>Remove leading and/or trailing white spaces and custom characters.</fsummary>
-      <type>
-        <v>Before = After = regexp()</v>
-        <v>String = Stripped = string()</v>
-      </type>
-      <desc>
-        <marker id="custom_clean"></marker>
-        <p><c>custom_clean/3</c> removes leading and/or trailing white
-	spaces and custom characters from <c>String</c>. <c>Before</c>
-	and <c>After</c> are regular expressions, as defined in
-	<c>regexp(3)</c>, describing the custom characters.</p>
-
-	<marker id="is_directory"></marker>
-      </desc>
-    </func>
-
-    <func>
-      <name>is_directory(FilePath) -> Result</name>
-      <fsummary>Check if a file path is a directory.</fsummary>
-      <type>
-        <v>FilePath = string()</v>
-        <v>Result = {ok,Directory} | {error,Reason}</v>
-        <v>Directory = string()</v>
-        <v>Reason = string() | enoent | eacces | enotdir | FileInfo</v>
-        <v>FileInfo = File info record</v>
-      </type>
-      <desc>
-        <marker id="is_directory"></marker>
-        <p><c>is_directory/1</c> checks if <c>FilePath</c> is a
-	directory in which case it is returned. Please read
-	<c>file(3)</c> for a description of <c>enoent</c>,
-	<c>eacces</c> and <c>enotdir</c>. The definition of 
-	the file info record can be found by including <c>file.hrl</c> 
-	from the kernel application, see file(3).</p>
-
-	<marker id="is_file"></marker>
-      </desc>
-    </func>
-
-    <func>
-      <name>is_file(FilePath) -> Result</name>
-      <fsummary>Check if a file path is a regular file.</fsummary>
-      <type>
-        <v>FilePath = string()</v>
-        <v>Result = {ok,File} | {error,Reason}</v>
-        <v>File = string()</v>
-        <v>Reason = string() | enoent | eacces | enotdir | FileInfo</v>
-        <v>FileInfo = File info record</v>
-      </type>
-      <desc>
-        <marker id="is_file"></marker>
-        <p><c>is_file/1</c> checks if <c>FilePath</c> is a regular
-	file in which case it is returned. Read <c>file(3)</c> for a
-	description of <c>enoent</c>, <c>eacces</c> and
-	<c>enotdir</c>. The definition of the file info record can be 
-	found by including <c>file.hrl</c> from the kernel application, 
-	see file(3).</p>
-
-	<marker id="make_integer"></marker>
-      </desc>
-    </func>
-
-    <func>
-      <name>make_integer(String) -> Result</name>
-      <fsummary>Return an integer representation of a string.</fsummary>
-      <type>
-        <v>String = string()</v>
-        <v>Result = {ok,integer()} | {error,nomatch}</v>
-      </type>
-      <desc>
-        <marker id="make_integer"></marker>
-        <p><c>make_integer/1</c> returns an integer representation of
-          <c>String</c>.</p>
-      </desc>
-    </func>
-  </funcs>
-
-  <section>
-    <marker id="see_also"></marker>
-    <title>SEE ALSO</title>
-    <p><seealso marker="httpd">httpd(3)</seealso></p>
-  </section>
-  
-</erlref>
-
-
diff --git a/lib/inets/doc/src/httpd_custom_api.xml b/lib/inets/doc/src/httpd_custom_api.xml
index 5840641b37..23417900fa 100644
--- a/lib/inets/doc/src/httpd_custom_api.xml
+++ b/lib/inets/doc/src/httpd_custom_api.xml
@@ -29,7 +29,7 @@
   <modulesummary>Behaviour with optional callbacks to customize the inets HTTP server.</modulesummary>
   <description>
     <p> The module implementing this behaviour shall be supplied to to the servers
-    configuration with the option <seealso marker="httpd:prop_customize"> customize</seealso></p>
+    configuration with the option <seealso marker="httpd#prop_customize"> customize</seealso></p>
     
   </description>  
   <funcs>
diff --git a/lib/inets/doc/src/httpd_socket.xml b/lib/inets/doc/src/httpd_socket.xml
index c0368c2b39..f71dac90b2 100644
--- a/lib/inets/doc/src/httpd_socket.xml
+++ b/lib/inets/doc/src/httpd_socket.xml
@@ -31,12 +31,12 @@
   </header>
   <module>httpd_socket</module>
   <modulesummary>Communication utility functions to be used by the Erlang
-    Web server API programmer.</modulesummary>
+    web server API programmer.</modulesummary>
   <description>
-    <p>This module provides the Erlang Web server API module programmer
+    <p>This module provides the Erlang web server API module programmer
     with utility functions for generic sockets communication. The
     appropriate communication mechanism is transparently used, that
-    is <c>ip_comm</c> or <c>ssl</c>.</p>
+    is, <c>ip_comm</c> or <c>ssl</c>.</p>
     
     <marker id="deliver"></marker>
   </description>
@@ -44,7 +44,7 @@
   <funcs>
     <func>
       <name>deliver(SocketType, Socket, Data) -> Result</name>
-      <fsummary>Send binary data over socket.</fsummary>
+      <fsummary>Sends binary data over socket.</fsummary>
       <type>
         <v>SocketType = socket_type()</v>
         <v>Socket = socket()</v>
@@ -53,10 +53,10 @@
       </type>
       <desc>
         <marker id="deliver"></marker>
-        <p><c>deliver/3</c> sends the <c>Binary</c> over the
-	<c>Socket</c> using the specified <c>SocketType</c>. Socket
-	and SocketType should be the socket and the socket_type form
-	the mod record as defined in httpd.hrl</p>
+        <p><c>deliver/3</c> sends <c>Data</c> over
+	<c>Socket</c> using the specified <c>SocketType</c>. <c>Socket</c>
+	and <c>SocketType</c> is to be the socket and the <c>socket_type</c> 
+	form the <c>mod</c> record as defined in <c>httpd.hrl</c></p>
     
 	<marker id="peername"></marker>
       </desc>
@@ -64,7 +64,7 @@
 
     <func>
       <name>peername(SocketType,Socket) -> {Port,IPAddress}</name>
-      <fsummary>Return the port and IP-address of the remote socket.</fsummary>
+      <fsummary>Returns the port and IP address of the remote socket.</fsummary>
       <type>
         <v>SocketType = socket_type()</v>
         <v>Socket = socket()</v>
@@ -73,8 +73,8 @@
       </type>
       <desc>
         <marker id="peername"></marker>
-        <p><c>peername/3</c> returns the <c>Port</c> and
-	<c>IPAddress</c> of the remote <c>Socket</c>. </p>
+        <p><c>peername/2</c> returns the <c>Port</c> and
+	<c>IPAddress</c> of the remote <c>Socket</c>.</p>
     
 	<marker id="resolve"></marker>
       </desc>
@@ -82,7 +82,7 @@
 
     <func>
       <name>resolve() -> HostName</name>
-      <fsummary>Return the official name of the current host.</fsummary>
+      <fsummary>Returns the official name of the current host.</fsummary>
       <type>
         <v>HostName = string()</v>
       </type>
diff --git a/lib/inets/doc/src/httpd_util.xml b/lib/inets/doc/src/httpd_util.xml
index a48e141368..0f498ba2fc 100644
--- a/lib/inets/doc/src/httpd_util.xml
+++ b/lib/inets/doc/src/httpd_util.xml
@@ -30,9 +30,10 @@
     <file>httpd_util.sgml</file>
   </header>
   <module>httpd_util</module>
-  <modulesummary>Miscellaneous utility functions to be used when implementing Erlang Web server API modules.</modulesummary>
+  <modulesummary>Miscellaneous utility functions to be used when implementing 
+  Erlang web server API modules.</modulesummary>
   <description>
-    <p>This module provides the Erlang Web Server API module
+    <p>This module provides the Erlang web server API module
       programmer with miscellaneous utility functions.</p>
 
     <marker id="convert_request_date"></marker>
@@ -41,7 +42,7 @@
   <funcs>
     <func>
       <name>convert_request_date(DateString) -> ErlDate|bad_date</name>
-      <fsummary>Convert The the date to the Erlang date format.</fsummary>
+      <fsummary>Converts the date to the Erlang date format.</fsummary>
       <type>
         <v>DateString = string()</v>
         <v>ErlDate = {{Year,Month,Date},{Hour,Min,Sec}}</v>
@@ -49,10 +50,9 @@
       </type>
       <desc>
         <p><c>convert_request_date/1</c> converts <c>DateString</c> to 
-          the Erlang date format. DateString must be in one of the three 
-          date formats that is defined in the RFC 2616.</p>
-
-	<marker id="create_etag"></marker>
+          the Erlang date format. <c>DateString</c> must be in one of the 
+	  three date formats defined in 
+	<url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>.</p>
       </desc>
     </func>
 
@@ -64,128 +64,84 @@
         <v>Etag = string()</v>
       </type>
       <desc>
-        <p><c>create_etag/1</c> calculates the Etag for a file, from its
-          size and time for last modification. fileinfo is a record defined 
-          in <c>kernel/include/file.hrl</c></p>
-
-	<marker id="decode_hex"></marker>
+        <p><c>create_etag/1</c> calculates the Etag for a file from its
+          size and time for last modification. <c>FileInfo</c> is a record defined 
+          in <c>kernel/include/file.hrl</c>.</p>
       </desc>
     </func>
-
-    <func>
-      <name>decode_hex(HexValue) -> DecValue</name>
-      <fsummary>Convert a hex value into its decimal equivalent.</fsummary>
-      <type>
-        <v>HexValue = DecValue = string()</v>
-      </type>
-      <desc>
-        <p>Converts the hexadecimal value <c>HexValue</c> into its
-          decimal equivalent (<c>DecValue</c>).</p>
-
-	<marker id="day"></marker>
-      </desc>
-    </func>
-
+    
     <func>
       <name>day(NthDayOfWeek) -> DayOfWeek</name>
-      <fsummary>Convert the day of the week (integer [1-7]) to an abbreviated string.</fsummary>
+      <fsummary>Converts the day of the week 
+      (integer [1-7]) to an abbreviated string.</fsummary>
       <type>
         <v>NthDayOfWeek = 1-7</v>
         <v>DayOfWeek = string()</v>
       </type>
       <desc>
-        <marker id="day"></marker>
         <p><c>day/1</c> converts the day of the week
-          (<c>NthDayOfWeek</c>) as an integer (1-7) to an abbreviated
-          string, that is: </p>
+          (<c>NthDayOfWeek</c>) from an integer (1-7) to an abbreviated
+          string, that is:</p>
         <p>1 = "Mon", 2 = "Tue", ..., 7 = "Sat".</p>
-
-	<marker id="flatlength"></marker>
       </desc>
     </func>
 
     <func>
-      <name>flatlength(NestedList) -> Size</name>
-      <fsummary>Compute the size of a possibly nested list.</fsummary>
+      <name>decode_hex(HexValue) -> DecValue</name>
+      <fsummary>Converts a hexadecimal value into its decimal equivalent.</fsummary>
       <type>
-        <v>NestedList = list()</v>
-        <v>Size = integer()</v>
+        <v>HexValue = DecValue = string()</v>
       </type>
       <desc>
-        <marker id="flatlength"></marker>
-        <p><c>flatlength/1</c> computes the size of the possibly nested
-          list <c>NestedList</c>. Which may contain binaries.</p>
-
-        <marker id="hexlist_to_integer"></marker>
+        <p>Converts the hexadecimal value <c>HexValue</c> into its
+          decimal equivalent (<c>DecValue</c>).</p>
       </desc>
     </func>
-
-<!--
+    
     <func>
-      <name>header(StatusCode,PersistentConn)</name>
-      <name>header(StatusCode,Date)</name>
-      <name>header(StatusCode,MimeType,Date)</name>
-      <name>header(StatusCode,MimeType,PersistentConn,Date) -> HTTPHeader</name>
-      <fsummary>Generate a HTTP 1.1 header.</fsummary>
+      <name>flatlength(NestedList) -> Size</name>
+      <fsummary>Computes the size of a possibly nested list.</fsummary>
       <type>
-        <v>StatusCode = integer()</v>
-        <v>Date = rfc1123_date()</v>
-        <v>MimeType = string()</v>
-        <v>PersistentConn = true | false</v>
+        <v>NestedList = list()</v>
+        <v>Size = integer()</v>
       </type>
       <desc>
-        <marker id="header"></marker>
-        <p><c>header</c> returns a HTTP 1.1 header string. The
-          <c>StatusCode</c> is one of the status codes defined in RFC
-          2616 and the <c>Date</c> string is RFC 1123 
-          compliant. (See <seealso marker="#rfc1123_date">rfc1123_date/0</seealso>).
-          </p>
-        <p>Note that the two version of <c>header/n</c> that does not
-          has a <c>PersistentConn</c> argument is there only for
-          backward compatibility, and must not be used in new Erlang
-          Webserver API modules.  that will support persistent
-          connections.</p>
-
-	<marker id="hexlist_to_integer"></marker>
+        <p><c>flatlength/1</c> computes the size of the possibly nested
+          list <c>NestedList</c>, which can contain binaries.</p>
       </desc>
     </func>
--->
 
     <func>
       <name>hexlist_to_integer(HexString) -> Number</name>
-      <fsummary>Convert a hexadecimal string to an integer.</fsummary>
+      <fsummary>Converts a hexadecimal string to an integer.</fsummary>
       <type>
         <v>Number = integer()</v>
         <v>HexString = string()</v>
       </type>
       <desc>
-        <p><c>hexlist_to_integer</c> Convert the Hexadecimal value of 
-          HexString to an integer.</p>
-
-	<marker id="integer_to_hexlist"></marker>
+        <p><c>hexlist_to_integer</c> converts the hexadecimal value of 
+          <c>HexString</c> to an integer.</p>
       </desc>
     </func>
 
     <func>
       <name>integer_to_hexlist(Number) -> HexString</name>
-      <fsummary>Convert an integer to a hexadecimal string.</fsummary>
+      <fsummary>Converts an integer to a hexadecimal string.</fsummary>
       <type>
         <v>Number = integer()</v>
         <v>HexString = string()</v>
       </type>
       <desc>
-        <marker id="integer_to_hexlist"></marker>
-        <p><c>integer_to_hexlist/1</c> Returns a string that represents 
-          the Number in a Hexadecimal form.</p>
-
-	<marker id="lookup"></marker>
+        <p><c>integer_to_hexlist/1</c> returns a string representing
+          <c>Number</c> in a hexadecimal form.</p>
       </desc>
     </func>
 
     <func>
       <name>lookup(ETSTable,Key) -> Result</name>
       <name>lookup(ETSTable,Key,Undefined) -> Result</name>
-      <fsummary>Extract the first value associated with a key in an ETS table.</fsummary>
+      <fsummary>Extracts the first value associated with a <c>Key</c> 
+      in an ETS table.</fsummary>
       <type>
         <v>ETSTable = ets_table()</v>
         <v>Key = term()</v>
@@ -195,20 +151,18 @@
       <desc>
         <p><c>lookup</c> extracts <c>{Key,Value}</c> tuples from
           <c>ETSTable</c> and returns the <c>Value</c> associated  
-          with <c>Key</c>. If <c>ETSTable</c> is of type <c>bag</c>
+          with <c>Key</c>. If <c>ETSTable</c> is of type <c>bag</c>,
           only the first <c>Value</c> associated with <c>Key</c> is
           returned. <c>lookup/2</c> returns <c>undefined</c> and
           <c>lookup/3</c> returns <c>Undefined</c> if no <c>Value</c>
           is found.</p>
-
-	<marker id="lookup_mime"></marker>
       </desc>
     </func>
 
     <func>
       <name>lookup_mime(ConfigDB,Suffix)</name>
       <name>lookup_mime(ConfigDB,Suffix,Undefined) -> MimeType</name>
-      <fsummary>Return the mime type associated with a specific file suffix. </fsummary>
+      <fsummary>Returns the MIME type associated with a specific file suffix.</fsummary>
       <type>
         <v>ConfigDB = ets_table()</v>
         <v>Suffix = string()</v>
@@ -216,20 +170,19 @@
         <v>Undefined = term()</v>
       </type>
       <desc>
-        <marker id="lookup_mime"></marker>
-        <p><c>lookup_mime</c> returns the mime type associated with a
-          specific file suffix as specified in the <c>mime.types</c>
-          file (located in the 
-          <path unix="$SERVER_ROOT/conf/mime.types" windows="%SERVER_ROOT%\conf\mime.types">config directory</path>).</p>
-
-	<marker id="lookup_mime_default"></marker>
+        <p><c>lookup_mime</c> returns the MIME type associated with a
+          specific file suffix as specified in the file <c>mime.types</c>
+          (located in the 
+          <path unix="$SERVER_ROOT/conf/mime.types" windows="%SERVER_ROOT%\conf\mime.types">
+	config directory</path>).</p>
       </desc>
     </func>
 
     <func>
       <name>lookup_mime_default(ConfigDB,Suffix)</name>
       <name>lookup_mime_default(ConfigDB,Suffix,Undefined) -> MimeType</name>
-      <fsummary>Return the mime type associated with a specific file suffix or the value of the DefaultType.</fsummary>
+      <fsummary>Returns the MIME type associated with a specific file suffix 
+      or the value of the DefaultType.</fsummary>
       <type>
         <v>ConfigDB = ets_table()</v>
         <v>Suffix = string()</v>
@@ -237,22 +190,19 @@
         <v>Undefined = term()</v>
       </type>
       <desc>
-        <marker id="lookup_mime_default"></marker>
-        <p><c>lookup_mime_default</c> returns the mime type associated
+        <p><c>lookup_mime_default</c> returns the MIME type associated
           with a specific file suffix as specified in the
           <c>mime.types</c> file (located in the
-          <path unix="$SERVER_ROOT/conf/mime.types" windows="%SERVER_ROOT%\conf\mime.types">config  directory</path>). 
-          If no appropriate association can be found 
-          the value of DefaultType is
+          <path unix="$SERVER_ROOT/conf/mime.types" windows="%SERVER_ROOT%\conf\mime.types">
+	    config  directory</path>). 
+          If no appropriate association is found, the value of <c>DefaultType</c> is
           returned.</p>
-
-	<marker id="message"></marker>
       </desc>
     </func>
 
     <func>
       <name>message(StatusCode,PhraseArgs,ConfigDB) -> Message</name>
-      <fsummary>Return an informative HTTP 1.1 status string in HTML.</fsummary>
+      <fsummary>Returns an informative HTTP 1.1 status string in HTML.</fsummary>
       <type>
         <v>StatusCode = 301 | 400 | 403 | 404 | 500 | 501 | 504</v>
         <v>PhraseArgs = term()</v>
@@ -260,53 +210,48 @@
         <v>Message = string()</v>
       </type>
       <desc>
-        <marker id="message"></marker>
         <p><c>message/3</c> returns an informative HTTP 1.1 status
           string in HTML. Each <c>StatusCode</c> requires a specific
           <c>PhraseArgs</c>:
           </p>
         <taglist>
           <tag><c>301</c></tag>
-          <item><c>string()</c>: A URL pointing at the new document
-           position.</item>
+          <item><p><c>string()</c>: A URL pointing at the new document
+           position.</p></item>
           <tag><c>400 | 401 | 500</c></tag>
-          <item><c>none</c> (No <c>PhraseArgs</c>)</item>
+          <item><p><c>none</c> (no <c>PhraseArgs</c>).</p></item>
           <tag><c>403 | 404</c></tag>
-          <item><c>string()</c>: A <c>Request-URI</c> as described in
-           RFC 2616.</item>
+          <item><p><c>string()</c>: A <c>Request-URI</c> as described in
+          <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>.</p>
+	  </item>
           <tag><c>501</c></tag>
-          <item><c>{Method,RequestURI,HTTPVersion}</c>: The HTTP
-          <c>Method</c>, <c>Request-URI</c> and <c>HTTP-Version</c>
-           as defined in RFC 2616.</item>
+          <item><p><c>{Method,RequestURI,HTTPVersion}</c>: The HTTP
+          <c>Method</c>, <c>Request-URI</c>, and <c>HTTP-Version</c>
+           as defined in RFC 2616.</p></item>
           <tag><c>504</c></tag>
-          <item><c>string()</c>: A string describing why the service
-           was unavailable.</item>
+          <item><p><c>string()</c>: A string describing why the service
+           was unavailable.</p></item>
         </taglist>
-
-	<marker id="month"></marker>
       </desc>
     </func>
 
     <func>
       <name>month(NthMonth) -> Month</name>
-      <fsummary>Convert the month as an integer (1-12) to an abbreviated string.</fsummary>
+      <fsummary>Converts the month as an integer (1-12) to an abbreviated string.</fsummary>
       <type>
         <v>NthMonth = 1-12</v>
         <v>Month = string()</v>
       </type>
       <desc>
-        <marker id="month"></marker>
         <p><c>month/1</c> converts the month <c>NthMonth</c> as an
           integer (1-12) to an abbreviated string, that is: </p>
         <p>1 = "Jan", 2 = "Feb", ..., 12 = "Dec".</p>
-
-	<marker id="multi_lookup"></marker>
       </desc>
     </func>
 
     <func>
       <name>multi_lookup(ETSTable,Key) -> Result</name>
-      <fsummary>Extract the values associated with a key in a ETS table.</fsummary>
+      <fsummary>Extracts the values associated with a key in an ETS table.</fsummary>
       <type>
         <v>ETSTable = ets_table()</v>
         <v>Key = term()</v>
@@ -314,49 +259,44 @@
       </type>
       <desc>
         <p><c>multi_lookup</c> extracts all <c>{Key,Value}</c> tuples
-          from an <c>ETSTable</c> and returns <em>all</em><c>Values</c> associated with the <c>Key</c> in a list.</p>
-
-	<marker id="reason phrase"></marker>
+          from an <c>ETSTable</c> and returns <em>all</em> <c>Values</c> 
+	associated with <c>Key</c> in a list.</p>
       </desc>
     </func>
 
     <func>
       <name>reason_phrase(StatusCode) -> Description</name>
-      <fsummary>Return the description of an HTTP 1.1 status code.</fsummary>
+      <fsummary>Returns the description of an HTTP 1.1 status code.</fsummary>
       <type>
-        <v>StatusCode = 100|  200 | 201 | 202 | 204 | 205 | 206 |  300 | 301 | 302 | 303 | 304 |  400 | 401 | 402 | 403 | 404 | 405 | 406 | 410 411 | 412 | 413 | 414 415 | 416 | 417 |  500 | 501 | 502 | 503 | 504 | 505</v>
+        <v>StatusCode = 100| 200 | 201 | 202 | 204 | 205 | 206 | 300 | 301 | 302 | 303 | 304 | 400 | 401 | 402 | 403 | 404 | 405 | 406 | 410 411 | 412 | 413 | 414 415 | 416 | 417 | 500 | 501 | 502 | 503 | 504 | 505</v>
         <v>Description = string()</v>
       </type>
       <desc>
-        <p><c>reason_phrase</c> returns the <c>Description</c> of an
-          HTTP 1.1 <c>StatusCode</c>, for example 200 is "OK" and 201
-          is "Created". Read RFC 2616 for further information.</p>
-
-	<marker id="rfc1123_date"></marker>
+        <p><c>reason_phrase</c> returns <c>Description</c> of an
+          HTTP 1.1 <c>StatusCode</c>, for example, 200 is "OK" and 201
+          is "Created". For more information, see
+	<url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>.</p>
       </desc>
     </func>
 
     <func>
       <name>rfc1123_date() -> RFC1123Date</name>
       <name>rfc1123_date({{YYYY,MM,DD},{Hour,Min,Sec}}) -> RFC1123Date</name>
-      <fsummary>Return the current date in RFC 1123 format.</fsummary>
+      <fsummary>Returns the current date in RFC 1123 format.</fsummary>
       <type>
         <v>YYYY = MM = DD = Hour = Min = Sec = integer()</v>
         <v>RFC1123Date = string()</v>
       </type>
       <desc>
-        <marker id="rfc1123_date"></marker>
         <p><c>rfc1123_date/0</c> returns the current date in RFC 1123
           format. <c>rfc_date/1</c> converts the date in the Erlang format
           to the RFC 1123 date format.</p>
-
-	<marker id="split"></marker>
       </desc>
     </func>
 
     <func>
       <name>split(String,RegExp,N) -> SplitRes</name>
-      <fsummary>Split a string in N chunks using a regular expression.</fsummary>
+      <fsummary>Splits a string in N chunks using a regular expression.</fsummary>
       <type>
         <v>String = RegExp = string()</v>
         <v>SplitRes = {ok, FieldList} | {error, errordesc()}</v>
@@ -364,96 +304,86 @@
         <v>N = integer</v>
       </type>
       <desc>
-        <marker id="split"></marker>
-        <p><c>split/3</c> splits the <c>String</c> in <c>N</c> chunks
-          using the <c>RegExp</c>. <c>split/3</c> is is equivalent to
-          <c>regexp:split/2</c> with one exception, that is <c>N</c>
-          defines the number of maximum number of fields in the
+        <p><c>split/3</c> splits <c>String</c> in <c>N</c> chunks
+          using <c>RegExp</c>. <c>split/3</c> is equivalent to
+          <c>regexp:split/2</c> with the exception that <c>N</c>
+          defines the maximum number of fields in
           <c>FieldList</c>.</p>
-
-	<marker id="split_script_path"></marker>
       </desc>
     </func>
 
     <func>
       <name>split_script_path(RequestLine) -> Splitted</name>
-      <fsummary>Split a <c>RequestLine</c>in a file reference to an executable and a<c>QueryString</c>or a <c>PathInfo</c>string.</fsummary>
+      <fsummary>Splits a <c>RequestLine</c> in a file reference to an executable, 
+      and a <c>QueryString</c> or a <c>PathInfo</c>string.</fsummary>
       <type>
         <v>RequestLine = string()</v>
         <v>Splitted = not_a_script | {Path, PathInfo, QueryString}</v>
         <v>Path = QueryString = PathInfo = string()</v>
       </type>
       <desc>
-        <marker id="split_script_path"></marker>
         <p><c>split_script_path/1</c> is equivalent to
           <c>split_path/1</c> with one exception. If the longest
-          possible path is not a regular, accessible and executable
-          file <c>not_a_script</c> is returned.</p>
-
-	<marker id="split_path"></marker>
+          possible path is not a regular, accessible, and executable
+          file, then <c>not_a_script</c> is returned.</p>
       </desc>
     </func>
 
     <func>
       <name>split_path(RequestLine) -> {Path,QueryStringOrPathInfo}</name>
-      <fsummary>Split a <c>RequestLine</c>in a file reference and a <c>QueryString</c>or a<c>PathInfo</c>string.</fsummary>
+      <fsummary>Splits a <c>RequestLine</c> in a file reference, and a 
+      <c>QueryString</c> or a <c>PathInfo</c> string.</fsummary>
       <type>
         <v>RequestLine = Path = QueryStringOrPathInfo = string()</v>
       </type>
       <desc>
-        <marker id="split_path"></marker>
-        <p><c>split_path/1</c> splits the <c>RequestLine</c> in a file
-          reference (<c>Path</c>) and a <c>QueryString</c> or a
-          <c>PathInfo</c> string as specified in RFC 2616. A
-          <c>QueryString</c> is isolated from the <c>Path</c> with a
+        <p><c>split_path/1</c> splits <c>RequestLine</c> in a file
+          reference (<c>Path</c>), and a <c>QueryString</c> or a
+          <c>PathInfo</c> string as specified in
+	  <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>.
+	  A <c>QueryString</c> is isolated from <c>Path</c> with a
           question mark (<c>?</c>) and <c>PathInfo</c> with a slash
           (/). In the case of a <c>QueryString</c>, everything before
-          the <c>?</c> is a <c>Path</c> and everything after a
-          <c>QueryString</c>. In the case of a <c>PathInfo</c> the
+          <c>?</c> is a <c>Path</c> and everything after <c>?</c> is a
+          <c>QueryString</c>. In the case of a <c>PathInfo</c>,
           <c>RequestLine</c> is scanned from left-to-right on the hunt
           for longest possible <c>Path</c> being a file or a
           directory. Everything after the longest possible
           <c>Path</c>, isolated with a <c>/</c>, is regarded as
           <c>PathInfo</c>. The resulting <c>Path</c> is decoded using
           <c>decode_hex/1</c> before delivery.</p>
-
-	<marker id="strip"></marker>
       </desc>
     </func>
 
     <func>
       <name>strip(String) -> Stripped</name>
-      <fsummary>Returns String where the leading and trailing space and tabs has been removed.</fsummary>
+      <fsummary>Returns <c>String</c> where the leading and trailing space 
+      tabs are removed.</fsummary>
       <type>
         <v>String = Stripped = string()</v>
       </type>
       <desc>
-        <marker id="strip"></marker>
         <p><c>strip/1</c> removes any leading or trailing linear white
-          space from the string.  Linear white space should be read as
+          space from the string. Linear white space is to be read as
           horizontal tab or space.</p>
-
-	<marker id="suffix"></marker>
       </desc>
     </func>
 
     <func>
       <name>suffix(FileName) -> Suffix</name>
-      <fsummary>Extract the file suffix from a given filename.</fsummary>
+      <fsummary>Extracts the file suffix from a given filename.</fsummary>
       <type>
         <v>FileName = Suffix = string()</v>
       </type>
       <desc>
-        <marker id="suffix"></marker>
         <p><c>suffix/1</c> is equivalent to
-          <c>filename:extension/1</c> with one exception, that is
-          <c>Suffix</c> is returned without a leading dot (<c>.</c>). </p>
+          <c>filename:extension/1</c> with the exception that
+          <c>Suffix</c> is returned without a leading dot (<c>.</c>).</p>
       </desc>
     </func>
   </funcs>
 
   <section>
-    <marker id="see_also"></marker>
     <title>SEE ALSO</title>
     <p><seealso marker="httpd">httpd(3)</seealso></p>
   </section>
diff --git a/lib/inets/doc/src/inets.xml b/lib/inets/doc/src/inets.xml
index f96ff5f8fb..5d071c9a48 100644
--- a/lib/inets/doc/src/inets.xml
+++ b/lib/inets/doc/src/inets.xml
@@ -30,21 +30,21 @@
     <rev></rev>
   </header>
   <module>inets</module>
-  <modulesummary>The inets services API</modulesummary>
+  <modulesummary>The Inets services API.</modulesummary>
   <description>
     <p>This module provides the most basic API to the 
-    clients and servers, that are part of the Inets application,
-    such as start and stop. </p>
+    clients and servers that are part of the <c>Inets</c> application,
+    such as start and stop.</p>
 
     <marker id="common_data_types"></marker>
   </description>
 
   <section>
-    <title>COMMON DATA TYPES </title>
+    <title>DATA TYPES</title>
     <p>Type definitions that are used more than once in
-      this module: </p>
-    <p><c> service() = ftpc | tftp | httpc | httpd</c></p>
-    <p><c> property() = atom() </c></p>
+      this module:</p>
+    <p><c>service() = ftpc | tftp | httpc | httpd</c></p>
+    <p><c>property() = atom()</c></p>
     <marker id="functions"></marker>
     <marker id="services"></marker>
   </section>
@@ -52,7 +52,7 @@
   <funcs>
     <func>
       <name>services() -> [{Service, Pid}]</name>
-      <fsummary>Returns a list of currently running services. </fsummary>
+      <fsummary>Returns a list of currently running services.</fsummary>
       <type>
         <v>Service = service()</v>
         <v>Pid = pid()</v>
@@ -60,7 +60,7 @@
       <desc>
         <p>Returns a list of currently running services.</p>
         <note>
-	  <p>Services started as <c>stand_alone</c> will not be listed.</p>
+	  <p>Services started as <c>stand_alone</c> are not listed.</p>
         </note>
 
 	<marker id="services_info"></marker>
@@ -70,8 +70,8 @@
     <func>
       <name>services_info() -> [{Service, Pid, Info}]</name>
       <fsummary>Returns a list of currently running services where
-      each service is described by a [{Option, Value}]
-      list. </fsummary>
+      each service is described by an <c>[{Option, Value}]</c>
+      list.</fsummary>
       <type>
         <v>Service = service()</v>
         <v>Pid = pid()</v>
@@ -81,11 +81,10 @@
       </type>
       <desc>
         <p>Returns a list of currently running services where each
-	service is described by a [{Option, Value}] list. The
-	information given in the list is specific for each service
-	and it is probable that each service will have its own info
-	function that gives you even more details about the
-	service.</p>
+	service is described by an <c>[{Option, Value}]</c> list. The
+	information in the list is specific for each service
+	and each service has probably its own info
+	function that gives more details about the service.</p>
 
 	<marker id="service_names"></marker>
       </desc>
@@ -107,59 +106,48 @@
     <func>
       <name>start() -> </name>
       <name>start(Type) -> ok | {error, Reason}</name>
-      <fsummary>Starts the Inets application. </fsummary>
+      <fsummary>Starts the <c>Inets</c> application.</fsummary>
       <type>
         <v>Type = permanent | transient | temporary</v>
       </type>
       <desc>
-        <p>Starts the Inets application. Default type
-	is temporary. See also
-	<seealso marker="kernel:application">application(3)</seealso>. </p>
+        <p>Starts the <c>Inets</c> application. Default type
+	is <c>temporary</c>. See also
+	<seealso marker="kernel:application">application(3)</seealso>.</p>
 
 	<marker id="stop"></marker>
       </desc>
     </func>
 
     <func>
-      <name>stop() -> ok </name>
-      <fsummary>Stops the inets application.</fsummary>
-      <desc>
-        <p>Stops the inets application. See also
-	<seealso marker="kernel:application">application(3)</seealso>. </p>
-	
-	<marker id="start2"></marker>
-      </desc>
-    </func>
-
-    <func>
       <name>start(Service, ServiceConfig) -> {ok, Pid} | {error, Reason}</name>
       <name>start(Service, ServiceConfig, How) -> {ok, Pid} | {error, Reason}</name>
-      <fsummary>Dynamically starts an inets
-      service after the inets application has been started. </fsummary>
+      <fsummary>Dynamically starts an <c>Inets</c>
+      service after the <c>Inets</c> application has been started.</fsummary>
       <type>
         <v>Service = service()</v>
         <v>ServiceConfig = [{Option, Value}]</v>
 	<v>Option = property()</v>
 	<v>Value = term()</v>
-        <v>How = inets | stand_alone - default is inets</v>
+        <v>How = inets | stand_alone - default is inets.</v>
       </type>
       <desc>
-        <p>Dynamically starts an inets service after the inets
-          application has been started. </p>
+        <p>Dynamically starts an <c>Inets</c> service after the <c>Inets</c>
+          application has been started.</p>
         <note>
-          <p>Dynamically started services will not be handled by
-            application takeover and failover behavior when inets is
-            run as a distributed application. Nor will they be
-            automatically restarted when the inets application is
-            restarted, but as long as the inets application is up and
-            running they will be supervised and may be soft code
-            upgraded. Services started as <c>stand_alone</c>,
-            e.i. the service is not started as part of the inets
-            application, will lose all OTP application benefits such
-            as soft upgrade. The "stand_alone-service" will be linked to
-            the process that started it. In most cases some of the
-            supervision functionality will still be in place and in
-            some sense the calling process has now become the top
+          <p>Dynamically started services are not handled by
+            application takeover and failover behavior when <c>Inets</c> is
+            run as a distributed application. Nor are they
+            automatically restarted when the <c>Inets</c> application is
+            restarted. As long as the <c>Inets</c> application is operational,
+	    they are supervised and can be soft code upgraded.</p>
+	    <p>A service started as <c>stand_alone</c>, that is, the service 
+	    is not started as part of the <c>Inets</c> application, 
+	    lose all OTP application benefits, such as soft upgrade. 
+	    The <c>stand_alone</c>-service is linked to
+            the process that started it. Usually some
+            supervision functionality is still in place and in
+            some sense the calling process becomes the top
             supervisor.</p>
         </note>
 	
@@ -167,19 +155,30 @@
       </desc>
     </func>
 
+     <func>
+      <name>stop() -> ok </name>
+      <fsummary>Stops the <c>Inets</c> application.</fsummary>
+      <desc>
+        <p>Stops the <c>Inets</c> application. See also
+	<seealso marker="kernel:application">application(3)</seealso>.</p>
+	
+	<marker id="start2"></marker>
+      </desc>
+    </func>
+    
     <func>
       <name>stop(Service, Reference) -> ok | {error, Reason} </name>
-      <fsummary>Stops a started service of the inets application or takes
-          down a "stand_alone-service" gracefully.</fsummary>
+      <fsummary>Stops a started service of the <c>Inets</c> application or takes
+          down a <c>stand_alone </c>service gracefully.</fsummary>
       <type>
 	<v>Service = service() | stand_alone</v>
-	<v>Reference = pid() | term() - service specified reference</v>
+	<v>Reference = pid() | term() - service-specified reference</v>
 	<v>Reason = term()</v>
       </type>
       <desc>
-        <p>Stops a started service of the inets application or takes
-	down a "stand_alone-service" gracefully. When the
-	<c>stand_alone</c> option is used in start,
+        <p>Stops a started service of the <c>Inets</c> application or takes
+	down a <c>stand_alone</c>-service gracefully. When option
+	<c>stand_alone</c> is used in start,
 	only the pid is a valid argument to stop.</p>
 	
 	<marker id="see_also"></marker>
diff --git a/lib/inets/doc/src/inets_services.xml b/lib/inets/doc/src/inets_services.xml
index f78485cb64..d100216ebb 100644
--- a/lib/inets/doc/src/inets_services.xml
+++ b/lib/inets/doc/src/inets_services.xml
@@ -22,7 +22,7 @@
     
     </legalnotice>
 
-    <title>Introduction</title>
+    <title>Inets</title>
     <prepared>Ingela Anderton Andin</prepared>
     <responsible></responsible>
     <docno></docno>
@@ -34,45 +34,26 @@
   </header>
 
   <section>
-    <title>Purpose</title>
-    <p>Inets is a container for Internet clients and
-      servers. Currently, an <term id="HTTP"></term>client and server, a
-      TFPT client and server, and a FTP client has been incorporated
-      into Inets. The HTTP server and client is HTTP 1.1 compliant as
-      defined in <term id="RFC"></term>2616.</p>
-  </section>
-
-  <section>
-    <title>Prerequisites</title>
-    <p>It is assumed that the reader is familiar with the Erlang
-      programming language, concepts of OTP and has a basic
-      understanding of the HTTP, TFTP and FTP protocols.</p>
-  </section>
-
-  <section>
-    <title>The Service Concept</title>
-    <p>Each client and server in inets is viewed as service.  Services
-      may be configured to be started at application startup or
-      started dynamically in runtime. If you want to run inets as an
-      distributed application that should handle application failover
-      and takeover, services should be configured to be started at
-      application startup. When starting the inets application
-      the inets top supervisor will start a number of subsupervisors
-      and worker processes for handling the different services
-      provided. When starting services dynamically new children will
-      be added to the supervision tree, unless the service is started
-      with the stand alone option, in which case the service is linked
-      to the calling process and all OTP application features such as
-      soft upgrade are lost.</p>
-    <p>Services that should be configured for startup at application
-      startup time should be put into the erlang node configuration file
-      on the form: </p>
+    <title>Service Concept</title>
+    <p>Each client and server in <c>Inets</c> is viewed as a service.
+      Services can be configured to be started at application startup or
+      dynamically in runtime. To run <c>Inets</c> as a distributed 
+      application that handles application failover and takeover, 
+      configure the services to be started at application startup. 
+      When starting the <c>Inets</c> application, the <c>Inets</c> 
+      top supervisor starts a number of subsupervisors and worker 
+      processes for handling the provided services.
+      When starting services dynamically, new children are added to the 
+      supervision tree, unless the service is started with the standalone 
+      option. In this case the service is linked to the calling process 
+      and all OTP application features, such as soft upgrade, are lost.</p>
+    <p>Services to be configured for startup at application startup are to 
+      be put into the Erlang node configuration file
+      on the following form:</p>
     <pre>
-      [{inets, [{services, ListofConfiguredServices}]}].
-    </pre>
-    <p>For details of exactly what to put in the list of configured
-      services see the documentation for the services that should be
-      configured.</p>
+      [{inets, [{services, ListofConfiguredServices}]}].</pre>
+    <p>For details of what to put in the list of configured services, 
+    see the documentation for the services to be configured.</p>
   </section>
 </chapter>
 
diff --git a/lib/inets/doc/src/introduction.xml b/lib/inets/doc/src/introduction.xml
new file mode 100644
index 0000000000..491835f852
--- /dev/null
+++ b/lib/inets/doc/src/introduction.xml
@@ -0,0 +1,57 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE chapter SYSTEM "chapter.dtd">
+
+<chapter>
+  <header>
+    <copyright>
+      <year>1997</year><year>2013</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>Introduction</title>
+    <prepared>Ingela Anderton Andin</prepared>
+    <responsible></responsible>
+    <docno></docno>
+    <approved></approved>
+    <checked></checked>
+    <date>2004-09-28</date>
+    <rev>A</rev>
+    <file>introduction.xml</file>
+  </header>
+
+  <section>
+    <title>Purpose</title>
+    <p><c>Inets</c> is a container for Internet clients and servers
+      including the following:</p>
+      <list type="bulleted">
+       <item>An FTP client</item>
+       <item>A TFTP client and server</item>
+       <item>An <term id="HTTP"></term> client and server</item>
+     </list>
+     <p>The HTTP client and server are HTTP 1.1 compliant as
+      defined in 
+     <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>.</p>
+  </section>
+
+  <section>
+    <title>Prerequisites</title>
+    <p>It is assumed that the reader is familiar with the Erlang
+      programming language, concepts of OTP, and has a basic
+      understanding of the FTP, TFTP, and HTTP protocols.</p>
+  </section>
+</chapter>
+
+
diff --git a/lib/inets/doc/src/mod_alias.xml b/lib/inets/doc/src/mod_alias.xml
index d073b5c5b8..87c950cc6b 100644
--- a/lib/inets/doc/src/mod_alias.xml
+++ b/lib/inets/doc/src/mod_alias.xml
@@ -32,8 +32,8 @@
   <module>mod_alias</module>
   <modulesummary>URL aliasing.</modulesummary>
   <description>
-    <p>Erlang Webserver Server internal API for handling of things
-    such as interaction data exported by the mod_alias module.</p>
+    <p>Erlang web server internal API for handling of, for example,
+    interaction data exported by module <c>mod_alias</c>.</p>
 
     <marker id="default_index"></marker>
   </description>
@@ -41,7 +41,7 @@
   <funcs>
     <func>
       <name>default_index(ConfigDB, Path) -> NewPath</name>
-      <fsummary>Return a new path with the default resource or file appended.</fsummary>
+      <fsummary>Returns a new path with the default resource or file appended.</fsummary>
       <type>
         <v>ConfigDB = config_db()</v>
         <v>Path = NewPath = string()</v>
@@ -50,14 +50,14 @@
         <marker id="default_index"></marker>
         <p>If <c>Path</c> is a directory, <c>default_index/2</c>, it starts
 	searching for resources or files that are specified in the config
-	directive DirectoryIndex.
+	directive <c>DirectoryIndex</c>.
 	If an appropriate resource or file is found, it is appended to
 	the end of <c>Path</c> and then returned. <c>Path</c> is
-	returned unaltered, if no appropriate
-	file is found, or if <c>Path</c> is not a directory.
+	returned unaltered if no appropriate
+	file is found or if <c>Path</c> is not a directory.
 	<c>config_db()</c> is the server config file in ETS table format
 	as described in
-	<seealso marker="http_server">Inets Users Guide.</seealso>.</p>
+	<seealso marker="http_server">Inets User's Guide</seealso>.</p>
 
 	<marker id="path"></marker>
       </desc>
@@ -65,7 +65,7 @@
 
     <func>
       <name>path(PathData, ConfigDB, RequestURI) -> Path</name>
-      <fsummary>Return the actual file path to a URL.</fsummary>
+      <fsummary>Returns the file path to a URL.</fsummary>
       <type>
         <v>PathData = interaction_data()</v>
         <v>ConfigDB = config_db()</v>
@@ -73,15 +73,16 @@
       </type>
       <desc>
         <marker id="path"></marker>
-        <p><c>path/3</c> returns the actual file <c>Path</c> in the
-	<c>RequestURI</c> (See RFC 1945). If the interaction data
-	<c>{real_name,{Path,AfterPath}}</c> has been exported by
-	mod_alias;
+        <p><c>path/3</c> returns the file <c>Path</c> in the
+	<c>RequestURI</c> (see 
+	<url href="http://www.rfc-base.org/rfc-1945.html">RFC 1945</url>). 
+	If the interaction data <c>{real_name,{Path,AfterPath}}</c> 
+	has been exported by <c>mod_alias</c>,
 	<c>Path</c> is returned. If no interaction data has been
-	exported, ServerRoot is used to
+	exported, <c>ServerRoot</c> is used to
 	generate a file <c>Path</c>. <c>config_db()</c> and
 	<c>interaction_data()</c> are as defined in 
-	<seealso marker="http_server">Inets Users Guide</seealso>.</p>
+	<seealso marker="http_server">Inets User's Guide</seealso>.</p>
 
 	<marker id="real_name"></marker>
       </desc>
@@ -89,7 +90,7 @@
 
     <func>
       <name>real_name(ConfigDB, RequestURI, Aliases) -> Ret</name>
-      <fsummary>Expand a request uri using  Alias config directives.</fsummary>
+      <fsummary>Expands a request URI using <c>Aliases</c> config directives.</fsummary>
       <type>
         <v>ConfigDB = config_db()</v>
         <v>RequestURI = string()</v>
@@ -101,18 +102,18 @@
         <marker id="real_name"></marker>
         <p><c>real_name/3</c> traverses <c>Aliases</c>, typically
 	extracted from <c>ConfigDB</c>, and matches each
-	<c>FakeName</c> with <c>RequestURI</c>. If a match is found 
+	<c>FakeName</c> with <c>RequestURI</c>. If a match is found, 
 	<c>FakeName</c> is replaced with <c>RealName</c> in the
-	match. The resulting path is split into two parts, that
-	is <c>ShortPath</c> and <c>AfterPath</c> as defined in 
-	<seealso marker="httpd_util#split_path">httpd_util:split_path/1</seealso>. 
-	<c>Path</c> is generated from <c>ShortPath</c>, that is
+	match. The resulting path is split into two parts,
+	<c>ShortPath</c> and <c>AfterPath</c>, as defined in 
+	<seealso marker="httpd_util#split_path-1">httpd_util:split_path/1</seealso>. 
+	<c>Path</c> is generated from <c>ShortPath</c>, that is,
 	the result from 
 	<seealso marker="#default_index">default_index/2</seealso> with
 	<c>ShortPath</c> as an argument.
 	<c>config_db()</c> is the server config file in ETS table
 	format as described in 
-	<seealso marker="http_server">Inets User Guide.</seealso>. </p>
+	<seealso marker="http_server">Inets User's Guide</seealso>.</p>
 
 	<marker id="real_script_name"></marker>
       </desc>
@@ -120,7 +121,8 @@
 
     <func>
       <name>real_script_name(ConfigDB, RequestURI, ScriptAliases) -> Ret</name>
-      <fsummary>Expand a request uri using ScriptAlias config directives.</fsummary>
+      <fsummary>Expands a request URI using <c>ScriptAliases</c> 
+      config directives.</fsummary>
       <type>
         <v>ConfigDB = config_db()</v>
         <v>RequestURI = string()</v>
@@ -132,14 +134,16 @@
         <marker id="real_script_name"></marker>
         <p><c>real_script_name/3</c> traverses <c>ScriptAliases</c>,
 	typically extracted from <c>ConfigDB</c>, and matches each
-	<c>FakeName</c> with <c>RequestURI</c>. If a match is found
+	<c>FakeName</c> with <c>RequestURI</c>. If a match is found,
 	<c>FakeName</c> is replaced with <c>RealName</c> in the
-	match. If the resulting match is not an executable script
-	<c>not_a_script</c> is returned. If it is a script the
-	resulting script path is in two parts, that is
-	<c>ShortPath</c> and <c>AfterPath</c> as defined in <seealso marker="httpd_util#split_script_path">httpd_util:split_script_path/1</seealso>.
+	match. If the resulting match is not an executable script,
+	<c>not_a_script</c> is returned. If it is a script, the
+	resulting script path is in two parts,
+	<c>ShortPath</c> and <c>AfterPath</c>, as defined in 
+	<seealso marker="httpd_util#split_script_path-1">httpd_util:split_script_path/1</seealso>.
 	<c>config_db()</c> is the server config file in ETS table
-	format as described in <seealso marker="http_server">Inets Users Guide.</seealso>.</p>
+	format as described in 
+	<seealso marker="http_server">Inets User's Guide</seealso>.</p>
       </desc>
     </func>
   </funcs>
diff --git a/lib/inets/doc/src/mod_auth.xml b/lib/inets/doc/src/mod_auth.xml
index fda945cf73..2da2be37ed 100644
--- a/lib/inets/doc/src/mod_auth.xml
+++ b/lib/inets/doc/src/mod_auth.xml
@@ -30,299 +30,267 @@
     <file>mod_auth.sgml</file>
   </header>
   <module>mod_auth</module>
-  <modulesummary>User authentication using text files, dets or mnesia database.</modulesummary>
+  <modulesummary>User authentication using text files, Dets, or Mnesia database.</modulesummary>
   <description>
     <p>This module provides for basic user authentication using
-    textual files, dets databases as well as mnesia databases. </p>
-
-    <marker id="add_user"></marker>
+    textual files, <c>Dets</c> databases, or <c>Mnesia</c> databases.</p>
   </description>
 
   <funcs>
+     <func>
+      <name>add_group_member(GroupName, UserName, Options) -> true | {error, Reason}</name>
+      <name>add_group_member(GroupName, UserName, Port, Dir) -> true | {error, Reason}</name>
+      <name>add_group_member(GroupName, UserName, Address, Port, Dir) -> true | {error, Reason}</name>
+      <fsummary>Adds a user to a group.</fsummary>
+      <type>
+        <v>GroupName = string()</v>
+        <v>UserName = string()</v>
+        <v>Options = [Option]</v>
+        <v>Option = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
+        <v>Port = integer()</v>
+        <v>Address = {A,B,C,D} | string() | undefined</v>
+        <v>Dir = string()</v>
+        <v>AuthPassword = string()</v>
+        <v>Reason = term()</v>
+      </type>
+      <desc>
+        <p><c>add_group_member/3, add_group_member/4</c>, and 
+	<c>add_group_member/5</c> each
+	adds a user to a group. If the group does not exist, it 
+	is created and the user is added to the group. Upon successful 
+	operation, this function returns <c>true</c>. 
+	When <c>add_group_members/3</c> 
+	is called, options <c>Port</c> and <c>Dir</c> are mandatory.</p>
+      </desc>
+    </func>
+    
     <func>
-      <name>add_user(UserName, Options) ->  true| {error, Reason}</name>
+      <name>add_user(UserName, Options) -> true| {error, Reason}</name>
       <name>add_user(UserName, Password, UserData, Port, Dir) -> true | {error, Reason}</name>
       <name>add_user(UserName, Password, UserData, Address, Port, Dir) -> true | {error, Reason}</name>
-      <fsummary>Add a user to the user database.</fsummary>
+      <fsummary>Adds a user to the user database.</fsummary>
       <type>
-        <v>UserName     = string()</v>
-        <v>Options     = [Option]</v>
-        <v>Option      = {password,Password} | {userData,UserData} | {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
-        <v>Password     = string()</v>
-        <v>UserData     = term()</v>
-        <v>Port         = integer()</v>
-        <v>Address      = {A,B,C,D} | string() | undefined</v>
-        <v>Dir          = string()</v>
+        <v>UserName = string()</v>
+        <v>Options = [Option]</v>
+        <v>Option = {password,Password} | {userData,UserData} | {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
+        <v>Password = string()</v>
+        <v>UserData = term()</v>
+        <v>Port = integer()</v>
+        <v>Address = {A,B,C,D} | string() | undefined</v>
+        <v>Dir = string()</v>
         <v>AuthPassword =string()</v>
-        <v>Reason       = term()</v>
+        <v>Reason = term()</v>
       </type>
       <desc>
-        <marker id="user_api"></marker>
-        <marker id="add_user"></marker>
-        <p><c>add_user/2, add_user/5</c> and <c>add_user/6</c> adds a 
-	user to the user 
-	database. If the operation is successful, this function returns 
-	<c>true</c>. If an error occurs, <c>{error,Reason}</c> is returned. 
-	When <c>add_user/2</c> is called the Password, 
-	UserData Port and Dir options is mandatory.</p>
-
-	<marker id="delete_user"></marker>
+        <p><c>add_user/2, add_user/5</c>, and <c>add_user/6</c> each adds a 
+	user to the user database. If the operation is successful, 
+	this function returns <c>true</c>. If an error occurs, 
+	<c>{error,Reason}</c> is returned. 
+	When <c>add_user/2</c> is called, options <c>Password</c>, 
+	<c>UserData</c>, <c>Port</c>, and <c>Dir</c> are mandatory.</p>
       </desc>
     </func>
 
-    <func>
-      <name>delete_user(UserName,Options)  -> true | {error, Reason}</name>
-      <name>delete_user(UserName, Port, Dir) -> true | {error, Reason}</name>
-      <name>delete_user(UserName, Address, Port, Dir) -> true | {error, Reason}</name>
-      <fsummary>Delete a user from the user database.</fsummary>
+     <func>
+      <name>delete_group(GroupName, Options) -> true | {error,Reason} &lt;name>delete_group(GroupName, Port, Dir) -> true | {error, Reason}</name>
+      <name>delete_group(GroupName, Address, Port, Dir) -> true | {error, Reason}</name>
+      <fsummary>Deletes a group.</fsummary>
       <type>
-        <v>UserName     = string()</v>
-        <v>Options      = [Option]</v>
-        <v>Option       = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
-        <v>Port         = integer()</v>
-        <v>Address      = {A,B,C,D} | string() | undefined</v>
-        <v>Dir          = string()</v>
+        <v>Options = [Option]</v>
+        <v>Option = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
+        <v>Port = integer()</v>
+        <v>Address = {A,B,C,D} | string() | undefined</v>
+        <v>Dir = string()</v>
+        <v>GroupName = string()</v>
         <v>AuthPassword = string()</v>
-        <v>Reason       = term()</v>
+        <v>Reason = term()</v>
       </type>
       <desc>
-        <marker id="delete_user"></marker>
-        <p><c>delete_user/2, delete_user/3</c> and <c>delete_user/4</c> 
-	deletes a user from the user database. 
-	If the operation is successful, this function returns <c>true</c>. 
-	If an error occurs, <c>{error,Reason}</c> is returned. 
-	When <c>delete_user/2</c> is called the Port and Dir options 
-	are mandatory.</p>
-
-	<marker id="get_user"></marker>
+	<p><c>delete_group/2, delete_group/3</c>, and <c>delete_group/4</c> 
+	each deletes the group specified and returns <c>true</c>. 
+	If there is an error, <c>{error, Reason}</c> is returned. 
+	When <c>delete_group/2</c> is called, option
+	<c>Port</c> and <c>Dir</c> are mandatory.</p>
       </desc>
     </func>
 
-    <func>
-      <name>get_user(UserName,Options) -> {ok, #httpd_user} |{error, Reason}</name>
-      <name>get_user(UserName, Port, Dir) -> {ok, #httpd_user} | {error, Reason}</name>
-      <name>get_user(UserName, Address, Port, Dir) -> {ok, #httpd_user} | {error, Reason}</name>
-      <fsummary>Returns a user from the user database.</fsummary>
+     <func>
+      <name>delete_group_member(GroupName, UserName, Options) -> true | {error, Reason}</name>
+      <name>delete_group_member(GroupName, UserName, Port, Dir) -> true | {error, Reason}</name>
+      <name>delete_group_member(GroupName, UserName, Address, Port, Dir) -> true | {error, Reason}</name>
+      <fsummary>Removes a user from a group.</fsummary>
       <type>
-        <v>UserName     = string()</v>
-        <v>Options      = [Option]</v>
-        <v>Option       = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
-        <v>Port         = integer()</v>
-        <v>Address      = {A,B,C,D} | string() | undefined</v>
-        <v>Dir          = string()</v>
+        <v>GroupName = string()</v>
+        <v>UserName = string()</v>
+        <v>Options = [Option]</v>
+        <v>Option = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
+        <v>Port = integer()</v>
+        <v>Address = {A,B,C,D} | string() | undefined</v>
+        <v>Dir = string()</v>
         <v>AuthPassword = string()</v>
-        <v>Reason       = term()</v>
+        <v>Reason = term()</v>
       </type>
       <desc>
-        <marker id="get_user"></marker>
-        <p><c>get_user/2, get_user/3</c> and <c>get_user/4</c> returns a 
-	<c>httpd_user</c> record containing the userdata for a 
-	specific user. If the user cannot be found, <c>{error, Reason}</c> 
-	is returned. When <c>get_user/2</c> is called the Port and Dir 
-	options are mandatory.</p>
-
-	<marker id="list_users"></marker>
+	<p><c>delete_group_member/3, delete_group_member/4</c>, and 
+	<c>delete_group_member/5</c> each deletes a user from a group. 
+	If the group or the user does not exist, 
+	this function returns an error, otherwise <c>true</c>.
+	When <c>delete_group_member/3</c> is called, the options <c>Port</c> 
+	and <c>Dir</c> are mandatory.</p>
       </desc>
     </func>
-
+    
     <func>
-      <name>list_users(Options) -> {ok, Users} | {error, Reason}</name>
-      <name>list_users(Port, Dir) -> {ok, Users} | {error, Reason}</name>
-      <name>list_users(Address, Port, Dir) -> {ok, Users} | {error, Reason}</name>
-      <fsummary>List users in the user database.</fsummary>
+      <name>delete_user(UserName,Options) -> true | {error, Reason}</name>
+      <name>delete_user(UserName, Port, Dir) -> true | {error, Reason}</name>
+      <name>delete_user(UserName, Address, Port, Dir) -> true | {error, Reason}</name>
+      <fsummary>Deletes a user from the user database.</fsummary>
       <type>
-        <v>Options      = [Option]</v>
-        <v>Option       = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
-        <v>Port         = integer()</v>
-        <v>Address      = {A,B,C,D} | string() | undefined</v>
-        <v>Dir          = string()</v>
-        <v>Users        = list()</v>
+        <v>UserName = string()</v>
+        <v>Options = [Option]</v>
+        <v>Option = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
+        <v>Port = integer()</v>
+        <v>Address = {A,B,C,D} | string() | undefined</v>
+        <v>Dir = string()</v>
         <v>AuthPassword = string()</v>
-        <v>Reason       = atom()</v>
+        <v>Reason = term()</v>
       </type>
       <desc>
-        <marker id="list_users"></marker>
-        <p><c>list_users/1, list_users/2</c> and <c>list_users/3</c> 
-	returns a list 
-	of users in the user database for a specific <c>Port/Dir</c>.
-	When <c>list_users/1</c> is called the Port and Dir 
-	options are mandatory.</p>
-
-	<marker id="add_group_member"></marker>
+        <p><c>delete_user/2, delete_user/3</c>, and <c>delete_user/4</c> 
+	each deletes a user from the user database. 
+	If the operation is successful, this function returns <c>true</c>. 
+	If an error occurs, <c>{error,Reason}</c> is returned. 
+	When <c>delete_user/2</c> is called, options <c>Port</c> and <c>Dir</c> 
+	are mandatory.</p>
       </desc>
     </func>
 
     <func>
-      <name>add_group_member(GroupName, UserName, Options) -> true | {error, Reason}</name>
-      <name>add_group_member(GroupName, UserName, Port, Dir) -> true | {error, Reason}</name>
-      <name>add_group_member(GroupName, UserName, Address, Port, Dir) -> true | {error, Reason}</name>
-      <fsummary>Add a user to a group.</fsummary>
+      <name>get_user(UserName,Options) -> {ok, #httpd_user} |{error, Reason}</name>
+      <name>get_user(UserName, Port, Dir) -> {ok, #httpd_user} | {error, Reason}</name>
+      <name>get_user(UserName, Address, Port, Dir) -> {ok, #httpd_user} | {error, Reason}</name>
+      <fsummary>Returns a user from the user database.</fsummary>
       <type>
-        <v>GroupName    = string()</v>
-        <v>UserName     = string()</v>
-        <v>Options      = [Option]</v>
-        <v>Option       = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
-        <v>Port         = integer()</v>
-        <v>Address      = {A,B,C,D} | string() | undefined</v>
-        <v>Dir          = string()</v>
+        <v>UserName = string()</v>
+        <v>Options = [Option]</v>
+        <v>Option = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
+        <v>Port = integer()</v>
+        <v>Address = {A,B,C,D} | string() | undefined</v>
+        <v>Dir = string()</v>
         <v>AuthPassword = string()</v>
-        <v>Reason       = term()</v>
+        <v>Reason = term()</v>
       </type>
       <desc>
-        <marker id="add_group_member"></marker>
-        <p><c>add_group_member/3, add_group_member/4</c> and 
-	<c>add_group_member/5</c> 
-	adds a user to a group. If the group does not exist, it 
-	is created and the user is added to the group. Upon successful 
-	operation, this function returns <c>true</c>. 
-	When <c>add_group_members/3</c> 
-	is called the Port and Dir options are mandatory.</p>
-
-	<marker id="delete_group_member"></marker>
+        <p><c>get_user/2, get_user/3</c>, and <c>get_user/4</c> each 
+	returns an <c>httpd_user</c> record containing the userdata for a 
+	specific user. If the user cannot be found, <c>{error, Reason}</c> 
+	is returned. When <c>get_user/2</c> is called, options <c>Port</c> and <c>Dir</c> 
+	are mandatory.</p>
       </desc>
     </func>
 
-    <func>
-      <name>delete_group_member(GroupName, UserName, Options) -> true | {error, Reason}</name>
-      <name>delete_group_member(GroupName, UserName, Port, Dir) -> true | {error, Reason}</name>
-      <name>delete_group_member(GroupName, UserName, Address, Port, Dir) -> true | {error, Reason}</name>
-      <fsummary>Remove a user from a group.</fsummary>
+     <func>
+      <name>list_groups(Options) -> {ok, Groups} | {error, Reason}</name>
+      <name>list_groups(Port, Dir) -> {ok, Groups} | {error, Reason}</name>
+      <name>list_groups(Address, Port, Dir) -> {ok, Groups} | {error, Reason}</name>
+      <fsummary>Lists all the groups.</fsummary>
       <type>
-        <v>GroupName    = string()</v>
-        <v>UserName     = string()</v>
-        <v>Options      = [Option]</v>
-        <v>Option       = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
-        <v>Port         = integer()</v>
-        <v>Address      = {A,B,C,D} | string() | undefined</v>
-        <v>Dir          = string()</v>
+        <v>Options = [Option]</v>
+        <v>Option = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
+        <v>Port = integer()</v>
+        <v>Address = {A,B,C,D} | string() | undefined</v>
+        <v>Dir = string()</v>
+        <v>Groups = list()</v>
         <v>AuthPassword = string()</v>
-        <v>Reason       = term()</v>
+        <v>Reason = term()</v>
       </type>
       <desc>
-        <marker id="delete_group_member"></marker>
-	<p><c>delete_group_member/3, delete_group_member/4</c> and 
-	<c>delete_group_member/5</c>  deletes a user from a group. 
-	If the group or the user does not exist, 
-	this function returns an error, otherwise it returns <c>true</c>.
-	When <c>delete_group_member/3</c> is called the Port and Dir options
-	are mandatory.</p>
-
-	<marker id="list_group_members"></marker>
+	<p><c>list_groups/1, list_groups/2</c>, and <c>list_groups/3</c> 
+	each lists all the groups available. 
+	If there is an error, <c>{error, Reason}</c> is returned. 
+	When <c>list_groups/1</c> is called, options <c>Port</c> 
+	and <c>Dir</c> are mandatory.</p>
       </desc>
     </func>
-
+   
     <func>
       <name>list_group_members(GroupName, Options) -> {ok, Users} | {error, Reason}</name>
       <name>list_group_members(GroupName, Port, Dir) -> {ok, Users} | {error, Reason}</name>
       <name>list_group_members(GroupName, Address, Port, Dir) -> {ok, Users} | {error, Reason}</name>
-      <fsummary>List the members of a group.</fsummary>
+      <fsummary>Lists the members of a group.</fsummary>
       <type>
-        <v>GroupName    = string()</v>
-        <v>Options      = [Option]</v>
-        <v>Option       = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
-        <v>Port         = integer()</v>
-        <v>Address      = {A,B,C,D} | string() | undefined</v>
-        <v>Dir          = string()</v>
-        <v>Users        = list()</v>
+        <v>GroupName = string()</v>
+        <v>Options = [Option]</v>
+        <v>Option = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
+        <v>Port = integer()</v>
+        <v>Address = {A,B,C,D} | string() | undefined</v>
+        <v>Dir = string()</v>
+        <v>Users = list()</v>
         <v>AuthPassword = string()</v>
-        <v>Reason       = term()</v>
+        <v>Reason = term()</v>
       </type>
       <desc>
-        <marker id="list_group_members"></marker>
-        <p><c>list_group_members/2, list_group_members/3</c> and 
-	<c>list_group_members/4</c> 
+        <p><c>list_group_members/2, list_group_members/3</c>, and 
+	<c>list_group_members/4</c> each
 	lists the members of a specified group. If the group does not 
 	exist or there is an error, <c>{error, Reason}</c> is returned.
-	When <c>list_group_members/2</c> is called the Port and Dir options
-	are mandatory.</p>
-
-	<marker id="list_groups"></marker>
+	When <c>list_group_members/2</c> is called, options <c>Port</c> 
+	and <c>Dir</c> are mandatory.</p>
       </desc>
     </func>
 
-    <func>
-      <name>list_groups(Options) -> {ok, Groups} | {error, Reason}</name>
-      <name>list_groups(Port, Dir) -> {ok, Groups} | {error, Reason}</name>
-      <name>list_groups(Address, Port, Dir) -> {ok, Groups} | {error, Reason}</name>
-      <fsummary>List all the groups.</fsummary>
+     <func>
+      <name>list_users(Options) -> {ok, Users} | {error, Reason}</name>
+      <name>list_users(Port, Dir) -> {ok, Users} | {error, Reason}</name>
+      <name>list_users(Address, Port, Dir) -> {ok, Users} | {error, Reason}</name>
+      <fsummary>Lists users in the user database.</fsummary>
       <type>
-        <v>Options      = [Option]</v>
-        <v>Option       = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
-        <v>Port         = integer()</v>
-        <v>Address      = {A,B,C,D} | string() | undefined</v>
-        <v>Dir          = string()</v>
-        <v>Groups       = list()</v>
+        <v>Options = [Option]</v>
+        <v>Option = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
+        <v>Port = integer()</v>
+        <v>Address = {A,B,C,D} | string() | undefined</v>
+        <v>Dir = string()</v>
+        <v>Users = list()</v>
         <v>AuthPassword = string()</v>
-        <v>Reason       = term()</v>
+        <v>Reason = atom()</v>
       </type>
       <desc>
-        <marker id="list_groups"></marker>
-	<p><c>list_groups/1, list_groups/2</c> and <c>list_groups/3</c> 
-	lists all the groups available. 
-	If there is an error, <c>{error, Reason}</c> is returned. 
-	When <c>list_groups/1</c> is called the Port and Dir options
+        <p><c>list_users/1, list_users/2</c>, and <c>list_users/3</c> 
+	each returns a list 
+	of users in the user database for a specific <c>Port/Dir</c>.
+	When <c>list_users/1</c> is called, options <c>Port</c> and <c>Dir</c> 
 	are mandatory.</p>
-
-	<marker id="delete_group"></marker>
       </desc>
     </func>
-
-    <func>
-      <name>delete_group(GroupName, Options) -> true | {error,Reason} &lt;name>delete_group(GroupName, Port, Dir) -> true | {error, Reason}</name>
-      <name>delete_group(GroupName, Address, Port, Dir) -> true | {error, Reason}</name>
-      <fsummary>Deletes a group</fsummary>
-      <type>
-        <v>Options      = [Option]</v>
-        <v>Option       = {port,Port} | {addr,Address} | {dir,Directory} | {authPassword,AuthPassword}</v>
-        <v>Port         = integer()</v>
-        <v>Address      = {A,B,C,D} | string() | undefined</v>
-        <v>Dir          = string()</v>
-        <v>GroupName    = string()</v>
-        <v>AuthPassword = string()</v>
-        <v>Reason       = term()</v>
-      </type>
-      <desc>
-        <marker id="delete_group"></marker>
-	<p><c>delete_group/2, delete_group/3</c> and <c>delete_group/4</c> 
-	deletes the group specified and returns <c>true</c>. 
-	If there is an error, <c>{error, Reason}</c> is returned. 
-	When <c>delete_group/2</c> is called the 
-	Port and Dir options are mandatory.</p>
-
-	<marker id="update_password"></marker>
-      </desc>
-    </func>
-
+    
     <func>
       <name>update_password(Port, Dir, OldPassword, NewPassword, NewPassword) -> ok | {error, Reason}</name>
       <name>update_password(Address,Port, Dir, OldPassword, NewPassword, NewPassword) -> ok | {error, Reason}</name>
-      <fsummary>Change the AuthAcessPassword</fsummary>
+      <fsummary>Changes <c>AuthAcessPassword</c>.</fsummary>
       <type>
-        <v>Port         = integer()</v>
-        <v>Address      = {A,B,C,D} | string() | undefined</v>
-        <v>Dir          = string()</v>
-        <v>GroupName    = string()</v>
-        <v>OldPassword  = string()</v>
-        <v>NewPassword  = string()</v>
-        <v>Reason       = term()</v>
+        <v>Port = integer()</v>
+        <v>Address = {A,B,C,D} | string() | undefined</v>
+        <v>Dir = string()</v>
+        <v>GroupName = string()</v>
+        <v>OldPassword = string()</v>
+        <v>NewPassword = string()</v>
+        <v>Reason = term()</v>
       </type>
       <desc>
-        <marker id="update_password"></marker>
-        <p><c>update_password/5</c> and <c>update_password/6</c> 
-	Updates the AuthAccessPassword for the specified directory. 
-	If NewPassword is equal to "NoPassword" no password is requires to
+        <p><c>update_password/5</c> and <c>update_password/6</c> each
+	updates <c>AuthAccessPassword</c> for the specified directory. 
+	If <c>NewPassword</c> is equal to "NoPassword", no password is required to
 	change authorisation data. 
-	If NewPassword is equal to "DummyPassword" no changes can be done 
+	If <c>NewPassword</c> is equal to "DummyPassword", no changes can be done 
 	without changing the password first.</p>
       </desc>
     </func>
   </funcs>
 
   <section>
-    <marker id="see_also"></marker>
     <title>SEE ALSO</title>
     <p><seealso marker="httpd">httpd(3)</seealso>,
-      <seealso marker="mod_alias">mod_alias(3)</seealso>,</p>
+      <seealso marker="mod_alias">mod_alias(3)</seealso></p>
   </section>
   
 </erlref>
diff --git a/lib/inets/doc/src/mod_esi.xml b/lib/inets/doc/src/mod_esi.xml
index 8044f46242..66c59a0c60 100644
--- a/lib/inets/doc/src/mod_esi.xml
+++ b/lib/inets/doc/src/mod_esi.xml
@@ -30,11 +30,11 @@
     <file>mod_esi.sgml</file>
   </header>
   <module>mod_esi</module>
-  <modulesummary>Erlang Server Interface </modulesummary>
+  <modulesummary>Erlang Server Interface</modulesummary>
   <description>
     <p>This module defines the Erlang Server Interface (ESI) API.
-    It is a more efficient way of writing erlang scripts
-    for your Inets web server than writing them as common CGI scripts.</p>
+    It is a more efficient way of writing Erlang scripts
+    for your <c>Inets</c> web server than writing them as common CGI scripts.</p>
 
     <marker id="deliver"></marker>
   </description>
@@ -42,7 +42,7 @@
   <funcs>
     <func>
       <name>deliver(SessionID, Data) -> ok | {error, Reason}</name>
-      <fsummary>Sends Data back to client.</fsummary>
+      <fsummary>Sends <c>Data</c> back to client.</fsummary>
       <type>
         <v>SessionID = term()</v>
         <v>Data = string() | io_list() | binary()</v>
@@ -53,16 +53,16 @@
 	<p>This function is <em>only</em> intended to be used from
 	functions called by the Erl Scheme interface to deliver
 	parts of the content to the user.</p>
-	<p>Sends data from a Erl Scheme script back to the client.</p>
+	<p>Sends data from an Erl Scheme script back to the client.</p>
 	
 	<note>
-	  <p>Note that if any HTTP-header fields should be added by the
-	  script they must be in the first call to deliver/2  and the
-	  data in the call must be a string. Calls after the headers
-	  are complete may contain binary data to reduce copying
-	  overhead.  Do not assume anything about the data type of 
-	  SessionID, the SessionID must be the value given as input to 
-	  the esi call back function that you implemented.</p>
+	  <p>If any HTTP header fields are added by the
+	  script, they must be in the first call to <c>deliver/2</c>, 
+	  and the data in the call must be a string. Calls after the headers
+	  are complete can contain binary data to reduce copying
+	  overhead. Do not assume anything about the data type of 
+	  <c>SessionID</c>. <c>SessionID</c> must be the value given 
+	  as input to the ESI callback function that you implemented.</p>
 	</note>
       </desc>
     </func>
@@ -74,54 +74,55 @@
   <funcs>
     <func>
       <name>Module:Function(SessionID, Env, Input)-> _ </name>
-      <fsummary>Creates a dynamic web page and returns it chunk by chunk to the server process by calling mod_esi:deliver/2.</fsummary>
+      <fsummary>Creates a dynamic web page and returns it chunk by chunk 
+      to the server process by calling <c>mod_esi:deliver/2</c>.</fsummary>
       <type>
         <v>SessionID = term()</v>
-        <v>Env  = [EnvironmentDirectives] ++ ParsedHeader</v>
+        <v>Env = [EnvironmentDirectives] ++ ParsedHeader</v>
         <v>EnvironmentDirectives = {Key,Value}</v>
         <v>Key = query_string | content_length | server_software | gateway_interface | server_protocol | server_port | request_method | remote_addr | script_name</v>
         <v>Input = string()</v>
       </type>
       <desc>
-        <p>The <c>Module</c> must be found in the code path and export
-          <c>Function</c> with an arity of three. An erlScriptAlias must
-          also be set up in the configuration file for the Web server.</p>
-        <p>If the HTTP request is a 'post' request and a body is sent
-          then content_length will be the length of the posted
-          data. If 'get' is used query_string will be the data after
-          <em>?</em> in the url.</p>
-        <p>ParsedHeader is the HTTP request as a key value tuple
-          list. The keys in parsed header will be the in lower case.</p>
-        <p>SessionID is a identifier
-          the server uses when <c>deliver/2</c> is called; do not
+        <p><c>Module</c> must be found in the code path and export
+          <c>Function</c> with an arity of three. An <c>erlScriptAlias</c> must
+          also be set up in the configuration file for the web server.</p>
+        <p>If the HTTP request is a 'post' request and a body is sent,
+          <c>content_length</c> is the length of the posted
+          data. If 'get' is used, <c>query_string</c> is the data after
+          <em>?</em> in the URL.</p>
+        <p><c>ParsedHeader</c> is the HTTP request as a key-value tuple
+          list. The keys in <c>ParsedHeader</c> are in lower case.</p>
+        <p><c>SessionID</c> is an identifier
+          the server uses when <c>deliver/2</c> is called. Do not
           assume anything about the datatype.</p>
-        <p>Use this callback function to dynamically generate dynamic web
-          content. When a part of the page is generated send the
-          data back to the client through <c>deliver/2</c>. Note
+        <p>Use this callback function to generate dynamic web
+          content dynamically. When a part of the page is generated, send the
+          data back to the client through <c>deliver/2</c>. Notice
           that the first chunk of data sent to the client must at
           least contain all HTTP header fields that the response
           will generate. If the first chunk does not contain the
-          <em>End of HTTP header</em>, that is <c>"\r\n\r\n",</c>
-          the server will
-          assume that no HTTP header fields will be generated.</p>
+          <em>end of HTTP header</em>, that is, <c>"\r\n\r\n",</c>
+          the server assumes that no HTTP header fields will be generated.</p>
       </desc>
     </func>
     <func>
       <name>Module:Function(Env, Input)-> Response </name>
-      <fsummary>Creates a dynamic web page and return it as a list. This functions is deprecated and only kept for backwards compatibility.</fsummary>
+      <fsummary>Creates a dynamic web page and returns it as a list. 
+      This function is deprecated and is only kept for backwards compatibility.</fsummary>
       <type>
-        <v>Env  = [EnvironmentDirectives] ++ ParsedHeader</v>
+        <v>Env = [EnvironmentDirectives] ++ ParsedHeader</v>
         <v>EnvironmentDirectives = {Key,Value}</v>
 		  <v>Key = query_string | content_length | server_software | gateway_interface | server_protocol | server_port | request_method | remote_addr | script_name.</v>
         <v>Input = string()</v>
         <v>Response = string()</v>
       </type>
       <desc>
-        <p>This callback format consumes a lot of memory since the
+        <p>This callback format consumes much memory, as the
           whole response must be generated before it is sent to the
-          user. This function is deprecated and only kept for backwards
+          user. This function is deprecated and is only kept for backwards
           compatibility.
-          For new development Module:Function/3 should be used.</p>
+          For new development, use <c>Module:Function/3</c>.</p>
       </desc>
     </func>
   </funcs>
diff --git a/lib/inets/doc/src/mod_security.xml b/lib/inets/doc/src/mod_security.xml
index 467c68d364..9dc32b971b 100644
--- a/lib/inets/doc/src/mod_security.xml
+++ b/lib/inets/doc/src/mod_security.xml
@@ -35,24 +35,45 @@
     <p>Security Audit and Trailing Functionality</p>
   </description>
   <funcs>
+
+      <func>
+      <name>block_user(User, Port, Dir, Seconds) -> true | {error, Reason}</name>
+      <name>block_user(User, Address, Port, Dir, Seconds) -> true | {error, Reason}</name>
+      <fsummary>Blocks a user from access to a directory for a certain amount of time.</fsummary>
+      <type>
+        <v>User = string()</v>
+        <v>Port = integer()</v>
+        <v>Address = {A,B,C,D} | string() | undefined</v>
+        <v>Dir = string()</v>
+        <v>Seconds = integer() | infinity</v>
+        <v>Reason = no_such_directory</v>
+      </type>
+      <desc>
+        <p><c>block_user/4</c> and <c>block_user/5</c> each blocks the user 
+          <c>User</c> from directory <c>Dir</c> for a specified 
+          amount of time.</p>
+      </desc>
+    </func>
+    
     <func>
       <name>list_auth_users(Port) -> Users | []</name>
       <name>list_auth_users(Address, Port) -> Users | []</name>
       <name>list_auth_users(Port, Dir) -> Users | []</name>
       <name>list_auth_users(Address, Port, Dir) -> Users | []</name>
-      <fsummary>List users that have authenticated within the SecurityAuthTimeout time for a given address (if specified), port number and directory  (if specified).</fsummary>
+      <fsummary>Lists users that have authenticated within the <c>SecurityAuthTimeout</c> 
+      time for a given address (if specified), port number, and directory 
+      (if specified).</fsummary>
       <type>
-        <v>Port    = integer()</v>
+        <v>Port = integer()</v>
         <v>Address = {A,B,C,D} | string() | undefined</v>
-        <v>Dir     = string()</v>
-        <v>Users   = list() = [string()]</v>
+        <v>Dir = string()</v>
+        <v>Users = list() = [string()]</v>
       </type>
       <desc>
-        <marker id="list_auth_users"></marker>
-        <p><c>list_auth_users/1</c>, <c>list_auth_users/2</c> and 
-          <c>list_auth_users/3</c> returns a list of users that are 
+        <p><c>list_auth_users/1</c>, <c>list_auth_users/2</c>, and 
+          <c>list_auth_users/3</c> each returns a list of users that are 
           currently authenticated. Authentications are stored for
-          SecurityAuthTimeout seconds, and are then discarded.</p>
+          <c>SecurityAuthTimeout</c> seconds, and then discarded.</p>
       </desc>
     </func>
     <func>
@@ -60,96 +81,83 @@
       <name>list_blocked_users(Address, Port) -> Users | []</name>
       <name>list_blocked_users(Port, Dir) -> Users | []</name>
       <name>list_blocked_users(Address, Port, Dir) -> Users | []</name>
-      <fsummary>List users that are currently blocked from access to a  specified port number, for a given address (if specified).</fsummary>
+      <fsummary>Lists users that are currently blocked from access to a 
+      specified port number, for a given address (if specified).</fsummary>
       <type>
-        <v>Port    = integer()</v>
+        <v>Port = integer()</v>
         <v>Address = {A,B,C,D} | string() | undefined</v>
-        <v>Dir     = string()</v>
-        <v>Users   = list() = [string()]</v>
+        <v>Dir = string()</v>
+        <v>Users = list() = [string()]</v>
       </type>
       <desc>
-        <marker id="list_blocked_users"></marker>
-        <p><c>list_blocked_users/1</c>, <c>list_blocked_users/2</c> and 
-          <c>list_blocked_users/3</c> returns a list of users that are 
+        <p><c>list_blocked_users/1</c>, <c>list_blocked_users/2</c>, and 
+          <c>list_blocked_users/3</c> each returns a list of users that are 
           currently blocked from access.</p>
       </desc>
     </func>
+  
     <func>
-      <name>block_user(User, Port, Dir, Seconds) -> true | {error, Reason}</name>
-      <name>block_user(User, Address, Port, Dir, Seconds) -> true | {error, Reason}</name>
-      <fsummary>Block user from access to a directory for a certain amount of time.</fsummary>
-      <type>
-        <v>User    = string()</v>
-        <v>Port    = integer()</v>
-        <v>Address = {A,B,C,D} | string() | undefined</v>
-        <v>Dir     = string()</v>
-        <v>Seconds = integer() | infinity</v>
-        <v>Reason  = no_such_directory</v>
-      </type>
-      <desc>
-        <marker id="block_user"></marker>
-        <p><c>block_user/4</c> and <c>block_user/5</c> blocks the user 
-          <c>User</c> from the directory <c>Dir</c> for a specified 
-          amount of time.</p>
-      </desc>
-    </func>
-    <func>
-      <name>unblock_user(User, Port)          -> true | {error, Reason}</name>
+      <name>unblock_user(User, Port) -> true | {error, Reason}</name>
       <name>unblock_user(User, Address, Port) -> true | {error, Reason}</name>
-      <name>unblock_user(User, Port, Dir)     -> true | {error, Reason}</name>
+      <name>unblock_user(User, Port, Dir) -> true | {error, Reason}</name>
       <name>unblock_user(User, Address, Port, Dir) -> true | {error, Reason}</name>
-      <fsummary>Remove a blocked user from the block list</fsummary>
+      <fsummary>Removes a blocked user from the block list.</fsummary>
       <type>
-        <v>User   = string()</v>
-        <v>Port   = integer()</v>
+        <v>User = string()</v>
+        <v>Port = integer()</v>
         <v>Address = {A,B,C,D} | string() | undefined</v>
-        <v>Dir    = string()</v>
+        <v>Dir = string()</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-        <marker id="unblock_user"></marker>
-        <p><c>unblock_user/2</c>, <c>unblock_user/3</c> and 
-          <c>unblock_user/4</c> removes the user <c>User</c> from 
-          the list of blocked users for the Port (and Dir) specified.</p>
+        <p><c>unblock_user/2</c>, <c>unblock_user/3</c>, and 
+          <c>unblock_user/4</c> each removes the user <c>User</c> from 
+          the list of blocked users for <c>Port</c> (and <c>Dir</c>).</p>
       </desc>
     </func>
   </funcs>
 
   <section>
     <marker id="callback_module"></marker>
-    <title>The SecurityCallbackModule</title>
-    <p>The SecurityCallbackModule is a user written module that can receive 
-      events from the mod_security Erlang Webserver API module. 
-      This module only exports the function(s),
-      <seealso marker="#callback_module_event">event/4,5</seealso>, 
-      which are described below.
+    <title>SecurityCallbackModule</title>
+    <p>The <c>SecurityCallbackModule</c> is a user-written module that can receive 
+      events from the <c>mod_security</c> Erlang web server API module. 
+      This module only exports the functions event/[4,5]
+      which are described here.
       </p>
   </section>
 
   <funcs>
     <func>
-      <name>event(What, Port, Dir, Data) -> ignored</name>
-      <name>event(What, Address, Port, Dir, Data) -> ignored</name>
-      <fsummary>This function is called whenever an event occurs in mod_security</fsummary>
+      <name>Module:event(What, Port, Dir, Data) -> ignored</name>
+      <name>Module:event(What, Address, Port, Dir, Data) -> ignored</name>
+      <fsummary>Called whenever an event occurs in <c>mod_security</c>.</fsummary>
       <type>
-        <v>What  = atom()</v>
-        <v>Port  = integer()</v>
+        <v>What = atom()</v>
+        <v>Port = integer()</v>
         <v>Address = {A,B,C,D} | string() &lt;v>Dir   = string()</v>
-        <v>Data  = [Info]</v>
-        <v>Info  = {Name, Value}</v>
+        <v>Data = [Info]</v>
+        <v>Info = {Name, Value}</v>
       </type>
       <desc>
         <marker id="callback_module_event"></marker>
-        <p><c>event/4</c> or <c>event/4</c> is called whenever an event 
-          occurs in the mod_security Erlang Webserver API module (<c>event/4</c> is
-          called if Address is undefined and <c>event/5</c> otherwise). 
-          The <c>What</c> argument specifies the type of event that has 
-          occurred, and should be one of the following reasons; 
-          <c>auth_fail</c> (a failed user authentication), 
-          <c>user_block</c> (a user is being blocked from access) or 
-          <c>user_unblock</c> (a user is being removed from the block list).</p>
+        <p><c>event/4</c> or <c>event/5</c> is called whenever an event 
+          occurs in the <c>mod_security</c> Erlang web server API module.
+	  (<c>event/4</c> is called if <c>Address</c> is undefined, 
+	  otherwise <c>event/5</c>. 
+          Argument <c>What</c> specifies the type of event that has 
+          occurred and is one of the following reasons:
+          </p>
+	  <taglist>
+       <tag><c>auth_fail</c></tag>
+       <item><p>A failed user authentication.</p></item>
+       <tag><c>user_block</c></tag>
+       <item><p>A user is being blocked from access.</p></item>
+       <tag><c>user_unblock</c></tag>
+       <item><p>A user is being removed from the block list.</p></item>
+     </taglist>
         <note>
-          <p>Note that the <c>user_unblock</c> event is not triggered when 
+          <p>The event <c>user_unblock</c> is not triggered when 
             a user is removed from the block list explicitly using the 
             <c>unblock_user</c> function.</p>
         </note>
diff --git a/lib/inets/doc/src/notes.xml b/lib/inets/doc/src/notes.xml
index d1bfa28013..6a6b9c8b23 100644
--- a/lib/inets/doc/src/notes.xml
+++ b/lib/inets/doc/src/notes.xml
@@ -765,9 +765,9 @@
           <p>Better handling of errorI(s) during update of the session 
 	  database. </p>
 	  <p>Also added and updated some debugging functions 
-	  <seealso marker="httpc#which_sessions">which_sessions/10,1</seealso>
+	  <seealso marker="httpc#which_sessions-0">which_sessions/[0,1]</seealso>
 	  and 
-	  <seealso marker="httpc#info">info/0</seealso>. </p>
+	  <seealso marker="httpc#info-0">info/0</seealso>. </p>
 	  <p>Own Id: OTP-10093</p>
           <p>Aux Id: Seq 12062</p>
         </item>
@@ -861,7 +861,7 @@
 
         <item>
           <p>[httpc] Add function for retrieving current options, 
-	  <seealso marker="httpc#get_options">get_options/1,2</seealso>. </p>
+	  <seealso marker="httpc#get_options-1">get_options/[1,2]</seealso>. </p>
 	  <p>Own Id: OTP-9979</p>
         </item>
 
@@ -1038,15 +1038,11 @@
 
     <section>
       <title>Incompatibilities</title>
-<!--
-      <p>-</p>
--->
-
       <list>
         <item>
           <p>[httpc] Deprecated interface module <c>http</c> has been removed. 
 	  It has (long) been replaced by http client interface module 
-	  <seealso marker="httpc#">httpc</seealso>. </p>
+	  <seealso marker="httpc">httpc</seealso>. </p>
 	  <p>Own Id: OTP-9359</p>
         </item>
 
@@ -1234,15 +1230,13 @@
   <section><title>Inets 5.6</title>
 
     <section><title>Improvements and New Features</title>
-<!--
-    <p>-</p>
--->
+
       <list>
         <item>
           <p>[httpc] Add support for upload body streaming (PUT and POST).</p>
 	  <p>For more info, 
 	  see the definition of the <c>Body</c> argument of the 
-	  <seealso marker="httpc#request2">request/4,5</seealso> 
+	  <seealso marker="httpc#request-4">request/[4,5]</seealso> 
 	  function. </p>
 	  <p>Filipe David Manana</p>
 	  <p>Own Id: OTP-9094</p>
@@ -1255,7 +1249,7 @@
 
         <item>
           <p>[httpd] 
-	  <seealso marker="mod_esi#deliver">mod_esi:deliver/2</seealso> 
+	  <seealso marker="mod_esi#deliver-2">mod_esi:deliver/2</seealso> 
 	  made to accept binary data. </p>
           <p>Bernard Duggan</p>
           <p>Own Id: OTP-9123</p>
@@ -1283,7 +1277,7 @@
 	  for using file descriptors has been improved. 
 	  It is now possible to add the file descriptor to the config 
 	  (option fd) when calling the 
-	  <seealso marker="inets#start2">inets:start(httpd, ...)</seealso> 
+	  <seealso marker="inets#start-2">inets:start(httpd, ...)</seealso> 
 	  function. </p>
 	  <p>Attila Rajmund Nohl</p>
           <p>Own Id: OTP-9202</p>
@@ -1297,7 +1291,7 @@
 	  <p>See the httpd 
 	  <seealso marker="httpd#props_comm">socket_type</seealso> 
 	  communication property or the httpc 
-	  <seealso marker="httpc#request2">request/4,5</seealso> function
+	  <seealso marker="httpc#request-4">request/[4,5]</seealso> function
 	  for more info. </p>
 	  <p>Own Id: OTP-9230</p>
 	  <p>*** POTENTIAL INCOMPATIBILITY ***</p>
@@ -1497,7 +1491,7 @@
 	  <p>[httpc|httpd] - Now allow the use of the "new" ssl, by using
             the <c>essl</c> tag instead. </p> 
           <p>See the <c>http_option</c> option in the 
-            <seealso marker="httpc#request2">request/4,5</seealso> or 
+            <seealso marker="httpc#request-4">request/[4,5]</seealso> or 
             the <seealso marker="httpd#props_comm">socket-type</seealso>
             section of the Communication properties chapter for more info, </p>
 	  <p>Own Id: OTP-7907</p>
@@ -1729,8 +1723,8 @@
 	  <p>[httpc] - Allow users to pass socket options to the transport 
             module when making requests. </p> 
           <p>See the <c>socket_opts</c> option in the 
-            <seealso marker="httpc#request2">request/4</seealso> or 
-            <seealso marker="httpc#set_options">set_options/1,2</seealso>
+            <seealso marker="httpc#request-4">request/4</seealso> or 
+            <seealso marker="httpc#set_options-1">set_options/[1,2]</seealso>
             for more info, </p>
 	  <p>Own Id: OTP-8352</p>
         </item>
@@ -1771,7 +1765,7 @@
             deliver an async reply to more receivers then the calling 
             process. </p> 
           <p>See the 
-            <seealso marker="httpc#request2">receiver</seealso>
+            <seealso marker="httpc#request-2">receiver</seealso>
             option for more info, </p>
 	  <p>Own Id: OTP-8106</p>
         </item>
@@ -2040,7 +2034,7 @@
               request, when the client connects to the server. Default 
               value is that of the <c>timeout</c> option. </p>
             <p>See the 
-	      <seealso marker="httpc#request2">request/4,5</seealso> 
+	      <seealso marker="httpc#request-4">request/[4,5]</seealso> 
               function for more info. </p>
 	    <p>Own Id: OTP-7298</p>
 	    <!-- <p>Aux Id: seq11086</p> -->
@@ -2147,7 +2141,7 @@
               the client connects to the server. </p>
 	    <p>As a side-effect of this, the option <c>ipv6</c> has been 
               removed and replaced by the <c>ipfamily</c> option. </p>
-	    <p>See <seealso marker="httpc#set_options">http:set_options/1,2</seealso> 
+	    <p>See <seealso marker="httpc#set_options-1">http:set_options/[1,2]</seealso> 
               for more info. </p>
             <p>*** POTENTIAL INCOMPATIBILITY ***</p>
 	    <p>Own Id: OTP-8004</p>
diff --git a/lib/inets/doc/src/part.xml b/lib/inets/doc/src/part.xml
index 1640ff507c..3b817eecf2 100644
--- a/lib/inets/doc/src/part.xml
+++ b/lib/inets/doc/src/part.xml
@@ -30,10 +30,18 @@
     <file>part.sgml</file>
   </header>
   <description>
-    <p>The <em>Inets Application </em> provides a set of Internet
-      related services. Currently supported are a HTTP client, a HTTP
-      server a FTP client and a TFTP client and server.</p>
+    <p>The <c>Inets</c> application provides a set of 
+    Internet-related services as follows:</p>
+      <list type="bulleted">
+       <item>An FTP client</item>
+       <item>A TFTP client and server</item>
+       <item>An <term id="HTTP"></term> client and server</item>
+     </list>
+     <p>The HTTP client and server are HTTP 1.1 compliant as
+      defined in
+     <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url>.</p>
   </description>
+  <xi:include href="introduction.xml"/>
   <xi:include href="inets_services.xml"/>
   <xi:include href="ftp_client.xml"/>
   <xi:include href="http_client.xml"/>
diff --git a/lib/inets/doc/src/ref_man.xml b/lib/inets/doc/src/ref_man.xml
index bcebcc0fd4..27021ea09a 100644
--- a/lib/inets/doc/src/ref_man.xml
+++ b/lib/inets/doc/src/ref_man.xml
@@ -30,16 +30,15 @@
     <file>ref_man.xml</file>
   </header>
   <description>
-    <p>Inets is a container for Internet clients and
-    servers. Currently a FTP client, a HTTP client and server, and
-    a tftp client and server has been incorporated in Inets.</p>
+    <p><c>Inets</c> is a container for Internet clients and
+    servers. An FTP client, an HTTP client and server, and
+    a TFTP client and server are incorporated in <c>Inets</c>.</p>
   </description>
   <xi:include href="inets.xml"/>
   <xi:include href="ftp.xml"/>
   <xi:include href="tftp.xml"/>
   <xi:include href="httpc.xml"/>
   <xi:include href="httpd.xml"/>
-  <xi:include href="httpd_conf.xml"/>
   <xi:include href="httpd_custom_api.xml"/>
   <xi:include href="httpd_socket.xml"/>
   <xi:include href="httpd_util.xml"/>
diff --git a/lib/inets/doc/src/tftp.xml b/lib/inets/doc/src/tftp.xml
index e70712fd1e..00d9d53376 100644
--- a/lib/inets/doc/src/tftp.xml
+++ b/lib/inets/doc/src/tftp.xml
@@ -29,173 +29,170 @@
     <rev></rev>
   </header>
   <module>tftp</module>
-  <modulesummary>Trivial FTP</modulesummary>
+  <modulesummary>Trivial FTP.</modulesummary>
   <description>
     <p>This is a complete implementation of the following IETF standards:</p>
     <list type="bulleted">
-      <item>RFC 1350, The TFTP Protocol (revision 2).</item>
-      <item>RFC 2347, TFTP Option Extension.</item>
-      <item>RFC 2348, TFTP Blocksize Option.</item>
-      <item>RFC 2349, TFTP Timeout Interval and Transfer Size Options.</item>
+      <item>RFC 1350, The TFTP Protocol (revision 2)</item>
+      <item>RFC 2347, TFTP Option Extension</item>
+      <item>RFC 2348, TFTP Blocksize Option</item>
+      <item>RFC 2349, TFTP Timeout Interval and Transfer Size Options</item>
     </list>
-    <p>The only feature that not is implemented in this release is
+    <p>The only feature that not is implemented is
       the "netascii" transfer mode.</p>
     <p>The <seealso marker="#start/1">start/1</seealso> function starts
-      a daemon process which listens for UDP packets on a port. When it
-      receives a request for read or write it spawns a temporary server
-      process which handles the actual transfer of the file.</p>
-    <p>On the client side
-      the <seealso marker="#read_file/3">read_file/3</seealso>
+      a daemon process listening for UDP packets on a port. When it
+      receives a request for read or write, it spawns a temporary server
+      process handling the transfer.</p>
+    <p>On the client side,
+      function <seealso marker="#read_file/3">read_file/3</seealso>
       and <seealso marker="#write_file/3">write_file/3</seealso>
-      functions spawns a temporary client process which establishes
-      contact with a TFTP daemon and performs the actual transfer of
-      the file.</p>
-    <p><c>tftp</c> uses a callback module to handle the actual file
+      spawn a temporary client process establishing
+      contact with a TFTP daemon and perform the file transfer.</p>
+    <p><c>tftp</c> uses a callback module to handle the file
       transfer. Two such callback modules are provided,
       <c>tftp_binary</c> and <c>tftp_file</c>. See
       <seealso marker="#read_file/3">read_file/3</seealso> and
-      <seealso marker="#write_file/3">write_file/3</seealso> for
-      more information about these. The user can also implement own
-      callback modules, see <seealso marker="#tftp_callback">CALLBACK FUNCTIONS</seealso> below. A callback module provided by
-      the user is registered using the <c>callback</c> option, see
-      <seealso marker="#options">DATA TYPES</seealso> below.</p>
+      <seealso marker="#write_file/3">write_file/3</seealso> for details.
+      You can also implement your own callback modules, see 
+      <seealso marker="#tftp_callback">CALLBACK FUNCTIONS</seealso>. 
+      A callback module provided by
+      the user is registered using option <c>callback</c>, see
+      <seealso marker="#options">DATA TYPES</seealso>.</p>
   </description>
   
  <section>
-    <title>TFTP SERVER SERVICE START/STOP </title>
+    <title>TFTP SERVER SERVICE START/STOP</title>
     
     <p>A TFTP server can be configured to start statically when starting
-      the Inets application. Alternatively it can be started dynamically
-      (when Inets already is started) by calling the Inets application API
-      <c>inets:start(tftpd, ServiceConfig)</c>, or
+      the <c>Inets</c> application. Alternatively, it can be started dynamically
+      (when <c>Inets</c> is already started) by calling the <c>Inets</c> application 
+      API <c>inets:start(tftpd, ServiceConfig)</c> or
       <c>inets:start(tftpd, ServiceConfig, How)</c>,
       see <seealso marker="inets">inets(3)</seealso> for details.
-      The <c>ServiceConfig</c> for TFTP is described below in
-      the <seealso marker="#options">COMMON DATA TYPES</seealso>
+      The <c>ServiceConfig</c> for TFTP is described in
+      the <seealso marker="#options">DATA TYPES</seealso>
       section.</p>
     
     <p>The TFTP server can be stopped using <c>inets:stop(tftpd, Pid)</c>,
       see <seealso marker="inets">inets(3)</seealso> for details.</p>
 
     <p>The TPFT client is of such a temporary nature that it is not
-      handled as a service in the Inets service framework.</p>
+      handled as a service in the <c>Inets</c> service framework.</p>
     
   </section>
   
   <section>
     <marker id="options"></marker>
-    <title>COMMON DATA TYPES</title>
-    <pre>
-      ServiceConfig = Options
-      Options = [option()]
-      option() -- see below
-    </pre>
+    <title>DATA TYPES</title>
+    <p><c>ServiceConfig = Options</c></p>
+    <p><c>Options = [option()]</c></p>
     <p>Most of the options are common for both the client and the server
-      side, but some of them differs a little. Here are the available
-      options:</p>
+      side, but some of them differs a little. 
+      The available <c>option()</c>s are as follows:</p>
     <taglist>
       <tag><c>{debug, Level}</c></tag>
       <item>
         <p><c>Level = none | error | warning | brief | normal | verbose | all</c></p>
-        <p>Controls the level of debug printouts. The default is
-          <c>none</c>.</p>
+        <p>Controls the level of debug printouts. 
+	Default is <c>none</c>.</p>
       </item>
       <tag><c>{host, Host}</c></tag>
       <item>
-        <p><c>Host = hostname()</c> see
-          <seealso marker="kernel:inet">inet(3)</seealso></p>
+        <p><c>Host = hostname()</c>, see
+          <seealso marker="kernel:inet">inet(3)</seealso>.</p>
         <p>The name or IP address of the host where the TFTP daemon
           resides. This option is only used by the client.</p>
       </item>
       <tag><c>{port, Port}</c></tag>
       <item>
         <p><c>Port = int()</c></p>
-        <p>The TFTP port where the daemon listens. It defaults to
-          the standardized number 69. On the server side it may
-          sometimes make sense to set it to 0, which means that
-          the daemon just will pick a free port (which one is
-          returned by the <c>info/1</c> function).</p>
-        <p>If a socket has somehow already has been connected, the
-          {udp, [{fd, integer()}]} option can be used to pass the
-          open file descriptor to gen_udp. This can be automated
-          a bit by using a command line argument stating the
+        <p>The TFTP port where the daemon listens. Defaults is
+          the standardized number 69. On the server side, it can
+          sometimes make sense to set it to 0, meaning that
+          the daemon just picks a free port (which one is
+          returned by function <c>info/1</c>).</p>
+        <p>If a socket is connected already, option
+          <c>{udp, [{fd, integer()}]}</c> can be used to pass the
+          open file descriptor to <c>gen_udp</c>. This can be automated
+          by using a command-line argument stating the
           prebound file descriptor number. For example, if the
-          Port is 69 and the file descriptor 22 has been opened by
-          setuid_socket_wrap. Then the command line argument
-          "-tftpd_69 22" will trigger the prebound file
+          port is 69 and file descriptor 22 is opened by
+          <c>setuid_socket_wrap</c>, the command-line argument
+          "-tftpd_69 22" triggers the prebound file
           descriptor 22 to be used instead of opening port 69.
-          The UDP option {udp, [{fd, 22}]} automatically be added.
-          See init:get_argument/ about command line arguments and
-          gen_udp:open/2 about UDP options.</p>
+          The UDP option <c>{udp, [{fd, 22}]}</c> is automatically added.
+          See <c>init:get_argument/</c> about command-line arguments and
+          <c>gen_udp:open/2</c> about UDP options.</p>
       </item>
       <tag><c>{port_policy, Policy}</c></tag>
       <item>
-        <p><c>Policy = random | Port | {range, MinPort, MaxPort}</c>          <br></br>
-<c>Port = MinPort = MaxPort = int()</c></p>
-        <p>Policy for the selection of the temporary port which is used
-          by the server/client during the file transfer. It defaults to
-          <c>random</c> which is the standardized policy. With this
-          policy a randomized free port used. A single port or a range
-          of ports can be useful if the protocol should pass through a
+        <p><c>Policy = random | Port | {range, MinPort, MaxPort}</c></p>
+	<p><c>Port = MinPort = MaxPort = int()</c></p>
+        <p>Policy for the selection of the temporary port that is used
+          by the server/client during the file transfer. Default is
+          <c>random</c>, which is the standardized policy. With this
+          policy a randomized free port is used. A single port or a range
+          of ports can be useful if the protocol passes through a
           firewall.</p>
       </item>
       <tag><c>{udp, Options}</c></tag>
       <item>
-        <p><c>Options = [Opt]</c> see
-          <seealso marker="kernel:gen_udp#open/1">gen_udp:open/2</seealso></p>
+        <p><c>Options = [Opt]</c>, see
+          <seealso marker="kernel:gen_udp#open/1">gen_udp:open/2</seealso>.</p>
       </item>
       <tag><c>{use_tsize, Bool}</c></tag>
       <item>
         <p><c>Bool = bool()</c></p>
-        <p>Flag for automated usage of the <c>tsize</c> option. With
-          this set to true, the <c>write_file/3</c> client will
-          determine the filesize and send it to the server as
+        <p>Flag for automated use of option <c>tsize</c>. With
+          this set to <c>true</c>, the <c>write_file/3</c> client
+          determines the filesize and sends it to the server as
           the standardized <c>tsize</c> option. A <c>read_file/3</c>
-          client will just acquire filesize from the server by sending
+          client acquires only a filesize from the server by sending
           a zero <c>tsize</c>.</p>
       </item>
       <tag><c>{max_tsize, MaxTsize}</c></tag>
       <item>
         <p><c>MaxTsize = int() | infinity</c></p>
         <p>Threshold for the maximal filesize in bytes. The transfer
-          will be aborted if the limit is exceeded. It defaults to
-          <c>infinity</c>.</p>
+          is aborted if the limit is exceeded. 
+	  Default is <c>infinity</c>.</p>
       </item>
       <tag><c>{max_conn, MaxConn}</c></tag>
       <item>
         <p><c>MaxConn = int() | infinity</c></p>
         <p>Threshold for the maximal number of active connections.
-          The daemon will reject the setup of new connections if
-          the limit is exceeded. It defaults to <c>infinity</c>.</p>
+          The daemon rejects the setup of new connections if
+          the limit is exceeded. Default is <c>infinity</c>.</p>
       </item>
       <tag><c>{TftpKey, TftpVal}</c></tag>
       <item>
         <p><c>TftpKey = string()</c>          <br></br>
 <c>TftpVal = string()</c></p>
-        <p>The name and value of a TFTP option.</p>
+        <p>Name and value of a TFTP option.</p>
       </item>
       <tag><c>{reject, Feature}</c></tag>
       <item>
         <p><c>Feature = Mode | TftpKey</c>          <br></br>
 <c>&nbsp;Mode = read | write</c>          <br></br>
 <c>&nbsp;TftpKey = string()</c></p>
-        <p>Control which features that should be rejected. This is
-          mostly useful for the server as it may restrict usage of
-          certain TFTP options or read/write access.</p>
+        <p>Controls which features to reject. This is
+          mostly useful for the server as it can restrict the use
+	  of certain TFTP options or read/write access.</p>
       </item>
       <tag><c>{callback, {RegExp, Module, State}}</c></tag>
       <item>
         <p><c>RegExp = string()</c>          <br></br>
 <c>Module = atom()</c>          <br></br>
-<c>State  = term()</c></p>
+<c>State = term()</c></p>
         <p>Registration of a callback module. When a file is to be
-          transferred, its local filename will be matched to the regular
+          transferred, its local filename is matched to the regular
           expressions of the registered callbacks. The first matching
-          callback will be used the during the transfer. See
+          callback is used during the transfer. See
           <seealso marker="#read_file/3">read_file/3</seealso> and
           <seealso marker="#write_file/3">write_file/3</seealso>.
           </p>
-        <p>The callback module must implement the <c>tftp</c> behavior,
+        <p>The callback module must implement the <c>tftp</c> behavior, see
           <seealso marker="#tftp_callback">CALLBACK FUNCTIONS</seealso>.</p>
       </item>
 
@@ -203,9 +200,9 @@
       <item>
         <p><c>Module = module()()</c></p>
 
-        <p>Callback module for customized logging of error, warning and
-	  info messages. >The callback module must implement the
-	  <c>tftp_logger</c> behavior,
+        <p>Callback module for customized logging of errors, warnings, and
+	  info messages. The callback module must implement the
+	  <c>tftp_logger</c> behavior, see
           <seealso marker="#tftp_logger">LOGGER FUNCTIONS</seealso>.
           The default module is <c>tftp_logger</c>.</p>
       </item>
@@ -215,8 +212,8 @@
         <p><c>MaxRetries = int()</c></p>
 
         <p>Threshold for the maximal number of retries. By default
-	  the server/client will try to resend a message up to
-	  <c>5</c> times when the timeout expires.</p>
+	  the server/client tries to resend a message up to
+	  five times when the time-out expires.</p>
       </item>
     </taglist>
 
@@ -224,98 +221,67 @@
   </section>
 
   <funcs>
+    <marker id="change_config_daemons"></marker>
     <func>
-      <name>start(Options) -> {ok, Pid} | {error, Reason}</name>
-      <fsummary>Start a daemon process</fsummary>
+      <name>change_config(daemons, Options) -> [{Pid, Result}]</name>
+      <fsummary>Changes configuration for all daemons.
+      </fsummary>
       <type>
         <v>Options = [option()]</v>
         <v>Pid = pid()</v>
+        <v>Result = ok | {error, Reason}</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-        <p>Starts a daemon process which listens for udp packets on a
-	port. When it receives a request for read or write it spawns
-	a temporary server process which handles the actual transfer
-	of the (virtual) file.</p>
+        <p>Changes configuration for all TFTP daemon processes. </p>
 	
-	<marker id="read_file"></marker>
+	<marker id="change_config_servers"></marker>
       </desc>
     </func>
 
     <func>
-      <name>read_file(RemoteFilename, LocalFilename, Options) -> {ok, LastCallbackState} | {error, Reason}</name>
-      <fsummary>Read a (virtual) file from a TFTP server</fsummary>
+      <name>change_config(servers, Options) -> [{Pid, Result}]</name>
+      <fsummary>Changes configuration for all servers.
+      </fsummary>
       <type>
-        <v>RemoteFilename = string()</v>
-        <v>LocalFilename = binary | string()</v>
         <v>Options = [option()]</v>
-        <v>LastCallbackState = term()</v>
+        <v>Pid = pid()</v>
+        <v>Result = ok | {error, Reason}</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-        <p>Reads a (virtual) file <c>RemoteFilename</c> from a TFTP
-	server.</p>
-	<p>If <c>LocalFilename</c> is the atom <c>binary</c>,
-	<c>tftp_binary</c> is used as callback module. It concatenates
-	all transferred blocks and returns them as one single binary
-	in <c>LastCallbackState</c>.</p>
-	<p>If <c>LocalFilename</c> is a string and there are no
-	registered callback modules, <c>tftp_file</c> is used as
-	callback module. It writes each transferred block to the file
-	named <c>LocalFilename</c> and returns the number of
-	transferred bytes in <c>LastCallbackState</c>.</p>
-	<p>If <c>LocalFilename</c> is a string and there are registered
-	callback modules, <c>LocalFilename</c> is tested against
-	the regexps of these and the callback module corresponding to
-	the first match is used, or an error tuple is returned if no
-	matching regexp is found.</p>
-      </desc>
+        <p>Changes configuration for all TFTP server processes.</p>
 	
-      <marker id="write_file"></marker>
+	<marker id="change_config_pid"></marker>
+      </desc>
     </func>
 
     <func>
-      <name>write_file(RemoteFilename, LocalFilename, Options) -> {ok, LastCallbackState} | {error, Reason}</name>
-      <fsummary>Write a (virtual) file to a TFTP server</fsummary>
+      <name>change_config(Pid, Options) -> Result</name>
+      <fsummary>Changes configuration for a TFTP daemon, server, 
+      or client process.</fsummary>
       <type>
-        <v>RemoteFilename = string()</v>
-        <v>LocalFilename = binary() | string()</v>
+        <v>Pid = pid()</v>
         <v>Options = [option()]</v>
-        <v>LastCallbackState = term()</v>
+        <v>Result = ok | {error, Reason}</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-        <p>Writes a (virtual) file <c>RemoteFilename</c> to a TFTP
-          server.</p>
-        <p>If <c>LocalFilename</c> is a binary, <c>tftp_binary</c> is
-          used as callback module. The binary is transferred block by
-          block and the number of transferred bytes is returned in
-          <c>LastCallbackState</c>.</p>
-        <p>If <c>LocalFilename</c> is a string and there are no
-          registered callback modules, <c>tftp_file</c> is used as
-          callback module. It reads the file named <c>LocalFilename</c>
-          block by block and returns the number of transferred bytes
-          in <c>LastCallbackState</c>.</p>
-        <p>If <c>LocalFilename</c> is a string and there are registered
-	callback modules, <c>LocalFilename</c> is tested against
-	the regexps of these and the callback module corresponding to
-	the first match is used, or an error tuple is returned if no
-	matching regexp is found.</p>
-	
+        <p>Changes configuration for a TFTP daemon, server, or client process.</p>
 	<marker id="info_daemons"></marker>
       </desc>
     </func>
-
+    
     <func>
       <name>info(daemons) -> [{Pid, Options}]</name>
-      <fsummary>Return information about all daemons</fsummary>
+      <fsummary>Returns information about all daemons.</fsummary>
       <type>
         <v>Pid = [pid()()]</v>
         <v>Options = [option()]</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-        <p>Returns info about all TFTP daemon processes. </p>
+        <p>Returns information about all TFTP daemon processes.</p>
 	
 	<marker id="info_servers"></marker>
       </desc>
@@ -323,14 +289,14 @@
 
     <func>
       <name>info(servers) -> [{Pid, Options}]</name>
-      <fsummary>Return information about all servers</fsummary>
+      <fsummary>Returns information about all servers.</fsummary>
       <type>
         <v>Pid = [pid()()]</v>
         <v>Options = [option()]</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-        <p>Returns info about all TFTP server processes. </p>
+        <p>Returns information about all TFTP server processes. </p>
 	
 	<marker id="info_pid"></marker>
       </desc>
@@ -338,117 +304,136 @@
 
     <func>
       <name>info(Pid) -> {ok, Options} | {error, Reason}</name>
-      <fsummary>Return information about a daemon, server or client process</fsummary>
+      <fsummary>Returns information about a daemon, server, or client process.</fsummary>
       <type>
         <v>Options = [option()]</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-        <p>Returns info about a TFTP daemon, server or client process.</p>
-	
-	<marker id="change_config_daemons"></marker>
+        <p>Returns information about a TFTP daemon, server, or client process.</p>
       </desc>
     </func>
-
-   <func>
-      <name>change_config(daemons, Options) -> [{Pid, Result}]</name>
-      <fsummary>Changes config for all daemons
-      </fsummary>
+       
+    <func>
+      <name>read_file(RemoteFilename, LocalFilename, Options) -> {ok, LastCallbackState} | {error, Reason}</name>
+      <fsummary>Reads a (virtual) file from a TFTP server.</fsummary>
       <type>
+        <v>RemoteFilename = string()</v>
+        <v>LocalFilename = binary | string()</v>
         <v>Options = [option()]</v>
-        <v>Pid = pid()</v>
-        <v>Result = ok | {error, Reason}</v>
+        <v>LastCallbackState = term()</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-        <p>Changes config for all TFTP daemon processes. </p>
-	
-	<marker id="change_config_servers"></marker>
+        <p>Reads a (virtual) file <c>RemoteFilename</c> from a TFTP
+	server.</p>
+	<p>If <c>LocalFilename</c> is the atom <c>binary</c>,
+	<c>tftp_binary</c> is used as callback module. It concatenates
+	all transferred blocks and returns them as one single binary
+	in <c>LastCallbackState</c>.</p>
+	<p>If <c>LocalFilename</c> is a string and there are no
+	registered callback modules, <c>tftp_file</c> is used as
+	callback module. It writes each transferred block to the file
+	named <c>LocalFilename</c> and returns the number of
+	transferred bytes in <c>LastCallbackState</c>.</p>
+	<p>If <c>LocalFilename</c> is a string and there are registered
+	callback modules, <c>LocalFilename</c> is tested against
+	the regexps of these and the callback module corresponding to
+	the first match is used, or an error tuple is returned if no
+	matching regexp is found.</p>
       </desc>
+	
+      <marker id="write_file"></marker>
     </func>
-
+    
     <func>
-      <name>change_config(servers, Options) -> [{Pid, Result}]</name>
-      <fsummary>Changes config for all servers
-      </fsummary>
+       <name>start(Options) -> {ok, Pid} | {error, Reason}</name>
+      <fsummary>Starts a daemon process.</fsummary>
       <type>
         <v>Options = [option()]</v>
         <v>Pid = pid()</v>
-        <v>Result = ok | {error, Reason}</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-        <p>Changes config for all TFTP server processes. </p>
+        <p>Starts a daemon process listening for UDP packets on a
+	port. When it receives a request for read or write, it spawns
+	a temporary server process handling the actual transfer
+	of the (virtual) file.</p>
 	
-	<marker id="change_config_pid"></marker>
+	<marker id="read_file"></marker>
       </desc>
     </func>
 
     <func>
-      <name>change_config(Pid, Options) -> Result</name>
-      <fsummary>Changes config for a TFTP daemon, server or client process</fsummary>
+      <name>write_file(RemoteFilename, LocalFilename, Options) -> {ok, LastCallbackState} | {error, Reason}</name>
+      <fsummary>Writes a (virtual) file to a TFTP server.</fsummary>
       <type>
-        <v>Pid = pid()</v>
+        <v>RemoteFilename = string()</v>
+        <v>LocalFilename = binary() | string()</v>
         <v>Options = [option()]</v>
-        <v>Result = ok | {error, Reason}</v>
-        <v>Reason = term()</v>
-      </type>
-      <desc>
-        <p>Changes config for a TFTP daemon, server or client process</p>
-	
-	<marker id="start2"></marker>
-      </desc>
-    </func>
-
-    <func>
-      <name>start() -> ok | {error, Reason}</name>
-      <fsummary>Start the Inets application</fsummary>
-      <type>
+        <v>LastCallbackState = term()</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-        <p>Starts the Inets application.</p>
+        <p>Writes a (virtual) file <c>RemoteFilename</c> to a TFTP
+          server.</p>
+        <p>If <c>LocalFilename</c> is a binary, <c>tftp_binary</c> is
+          used as callback module. The binary is transferred block by
+          block and the number of transferred bytes is returned in
+          <c>LastCallbackState</c>.</p>
+        <p>If <c>LocalFilename</c> is a string and there are no
+          registered callback modules, <c>tftp_file</c> is used as
+          callback module. It reads the file named <c>LocalFilename</c>
+          block by block and returns the number of transferred bytes
+          in <c>LastCallbackState</c>.</p>
+        <p>If <c>LocalFilename</c> is a string and there are registered
+	callback modules, <c>LocalFilename</c> is tested against
+	the regexps of these and the callback module corresponding to
+	the first match is used, or an error tuple is returned if no
+	matching regexp is found.</p>
       </desc>
     </func>
+   
   </funcs>
 
   <section>
     <marker id="tftp_callback"></marker>
     <title>CALLBACK FUNCTIONS</title>
-    <p>A <c>tftp</c> callback module should be implemented as a
-      <c>tftp</c> behavior and export the functions listed below.</p>
-    <p>On the server side the callback interaction starts with a call to
+    <p>A <c>tftp</c> callback module is to be implemented as a
+      <c>tftp</c> behavior and export the functions listed
+      in the following.</p>
+    <p>On the server side, the callback interaction starts with a call to
       <c>open/5</c> with the registered initial callback state.
       <c>open/5</c> is expected to open the (virtual) file. Then either
-      the <c>read/1</c> or <c>write/2</c> functions are invoked
-      repeatedly, once per transferred block. At each function call
+      function <c>read/1</c> or <c>write/2</c> is invoked
+      repeatedly, once per transferred block. At each function call,
       the state returned from the previous call is obtained. When
-      the last block has been encountered the <c>read/1</c> or
-      <c>write/2</c> functions is expected to close the (virtual) file
-      and return its last state. The <c>abort/3</c> function is only
-      used in error situations. <c>prepare/5</c> is not used on
+      the last block is encountered, function <c>read/1</c> or
+      <c>write/2</c> is expected to close the (virtual) file
+      and return its last state. Function <c>abort/3</c> is only
+      used in error situations. Function <c>prepare/5</c> is not used on
       the server side.</p>
-    <p>On the client side the callback interaction is the same, but it
+    <p>On the client side, the callback interaction is the same, but it
       starts and ends a bit differently. It starts with a call to
       <c>prepare/5</c> with the same arguments as <c>open/5</c> takes.
-      <c>prepare/5</c> is expected to validate the TFTP options,
-      suggested by the user and return the subset of them that it
-      accepts. Then the options is sent to the server which will perform
+      <c>prepare/5</c> is expected to validate the TFTP options
+      suggested by the user and to return the subset of them that it
+      accepts. Then the options are sent to the server, which performs
       the same TFTP option negotiation procedure. The options that are
-      accepted by the server are forwarded to the <c>open/5</c> function
-      on the client side. On the client side the <c>open/5</c> function
-      must accept all option as is or reject the transfer. Then
+      accepted by the server are forwarded to function <c>open/5</c>
+      on the client side. On the client side, function <c>open/5</c>
+      must accept all option as-is or reject the transfer. Then
       the callback interaction follows the same pattern as described
-      above for the server side. When the last block is encountered in
-      <c>read/1</c> or <c>write/2</c> the returned state is forwarded to
+      for the server side. When the last block is encountered in
+      <c>read/1</c> or <c>write/2</c>, the returned state is forwarded to
       the user and returned from <c>read_file</c>/3 or
       <c>write_file/3</c>.</p>
 
-    <p> If a callback (which performs the file access
+    <p> If a callback (performing the file access
     in the TFTP server) takes too long time (more than
-    the double TFTP timeout), the server will abort the
-    connection and send an error reply to the client.
-    This implies that the server will release resources
+    the double TFTP time-out), the server aborts the
+    connection and sends an error reply to the client.
+    This implies that the server releases resources
     attached to the connection faster than before. The
     server simply assumes that the client has given
     up.</p>
@@ -456,21 +441,45 @@
     <p>If the TFTP server receives yet another request from
     the same client (same host and port) while it
     already has an active connection to the client, it
-    will simply ignore the new request if the request is
-    equal with the first one (same filename and options).
+    ignores the new request if the request is
+    equal to the first one (same filename and options).
     This implies that the (new) client will be served
     by the already ongoing connection on the server
     side. By not setting up yet another connection, in
-    parallel with the ongoing one, the server will
-    consumer lesser resources. </p>
+    parallel with the ongoing one, the server
+    consumes less resources.</p>
     
     <marker id="prepare"></marker>
   </section>
 
   <funcs>
-    <func>
-      <name>prepare(Peer, Access, Filename, Mode, SuggestedOptions, InitialState) -> {ok, AcceptedOptions, NewState} | {error, {Code, Text}}</name>
-      <fsummary>Prepare to open a file on the client side</fsummary>
+     <func>
+      <name>Module:abort(Code, Text, State) -> ok</name>
+      <fsummary>Aborts the file transfer.</fsummary>
+      <type>
+        <v>Code = undef | enoent | eacces | enospc</v>
+        <v>&nbsp;&nbsp;| badop | eexist | baduser | badopt</v>
+        <v>&nbsp;&nbsp;| int()</v>
+        <v>Text = string()</v>
+        <v>State = term()</v>
+      </type>
+      <desc>
+        <p>Invoked when the file transfer is aborted.</p>
+        <p>The callback function is expected to clean
+	up its used resources after the aborted file
+	transfer, such as closing open file
+	descriptors and so on. The function is not
+	invoked if any of the other callback
+	functions returns an error, as it is
+	expected that they already have cleaned up
+	the necessary resources. However, it is
+	invoked if the functions fail (crash).</p>
+      </desc>
+    </func>
+    
+      <func>
+      <name>Module:open(Peer, Access, Filename, Mode, SuggestedOptions, State) -> {ok, AcceptedOptions, NewState} | {error, {Code, Text}}</name>
+      <fsummary>Opens a file for read or write access.</fsummary>
       <type>
         <v>Peer = {PeerType, PeerHost, PeerPort}</v>
         <v>PeerType = inet | inet6</v>
@@ -481,7 +490,8 @@
         <v>Mode = string()</v>
         <v>SuggestedOptions = AcceptedOptions = [{Key, Value}]</v>
         <v>&nbsp;Key = Value = string()</v>
-        <v>InitialState = [] | [{root_dir, string()}]</v>
+        <v>State = InitialState | term()</v>
+        <v>&nbsp;InitialState = [] | [{root_dir, string()}]</v>
         <v>NewState = term()</v>
         <v>Code = undef | enoent | eacces | enospc</v>
         <v>&nbsp;&nbsp;| badop | eexist | baduser | badopt</v>
@@ -489,23 +499,22 @@
         <v>Text = string()</v>
       </type>
       <desc>
-	<p>Prepares to open a file on the client side.</p>
-	<p>No new options may be added, but the ones that are present in
-	<c>SuggestedOptions</c> may be omitted or replaced with new
-	values in <c>AcceptedOptions</c>.</p>
-	<p>Will be followed by a call to <c>open/4</c> before any
-	read/write access is performed. <c>AcceptedOptions</c> is
-	sent to the server which replies with those options that it
-	accepts. These will be forwarded to <c>open/4</c> as
-	<c>SuggestedOptions</c>.</p>
+        <p>Opens a file for read or write access.</p>
+        <p>On the client side, where the <c>open/5</c> call has been
+	preceded by a call to <c>prepare/5</c>, all options must be
+	accepted or rejected.</p>
+	<p>On the server side, where there is no preceding
+	<c>prepare/5</c> call, no new options can be added, but
+	those present in <c>SuggestedOptions</c> can be
+	omitted or replaced with new values in <c>AcceptedOptions</c>.</p>
     
-	<marker id="open"></marker>
+	<marker id="read"></marker>
       </desc>
     </func>
-
+    
     <func>
-      <name>open(Peer, Access, Filename, Mode, SuggestedOptions, State) -> {ok, AcceptedOptions, NewState} | {error, {Code, Text}}</name>
-      <fsummary>Open a file for read or write access</fsummary>
+      <name>Module:prepare(Peer, Access, Filename, Mode, SuggestedOptions, InitialState) -> {ok, AcceptedOptions, NewState} | {error, {Code, Text}}</name>
+      <fsummary>Prepares to open a file on the client side.</fsummary>
       <type>
         <v>Peer = {PeerType, PeerHost, PeerPort}</v>
         <v>PeerType = inet | inet6</v>
@@ -516,8 +525,7 @@
         <v>Mode = string()</v>
         <v>SuggestedOptions = AcceptedOptions = [{Key, Value}]</v>
         <v>&nbsp;Key = Value = string()</v>
-        <v>State = InitialState | term()</v>
-        <v>&nbsp;InitialState = [] | [{root_dir, string()}]</v>
+        <v>InitialState = [] | [{root_dir, string()}]</v>
         <v>NewState = term()</v>
         <v>Code = undef | enoent | eacces | enospc</v>
         <v>&nbsp;&nbsp;| badop | eexist | baduser | badopt</v>
@@ -525,22 +533,23 @@
         <v>Text = string()</v>
       </type>
       <desc>
-        <p>Opens a file for read or write access.</p>
-        <p>On the client side where the <c>open/5</c> call has been
-	preceded by a call to <c>prepare/5</c>, all options must be
-	accepted or rejected.</p>
-	<p>On the server side, where there is no preceding
-	<c>prepare/5</c> call, no new options may be added, but
-	the ones that are present in <c>SuggestedOptions</c> may be
-	omitted or replaced with new values in <c>AcceptedOptions</c>.</p>
+	<p>Prepares to open a file on the client side.</p>
+	<p>No new options can be added, but those present in
+	<c>SuggestedOptions</c> can be omitted or replaced with new
+	values in <c>AcceptedOptions</c>.</p>
+	<p>This is followed by a call to <c>open/4</c> before any
+	read/write access is performed. <c>AcceptedOptions</c> is
+	sent to the server, which replies with the options that it
+	accepts. These are then forwarded to <c>open/4</c> as
+	<c>SuggestedOptions</c>.</p>
     
-	<marker id="read"></marker>
+	<marker id="open"></marker>
       </desc>
     </func>
 
     <func>
-      <name>read(State) -> {more, Bin, NewState} | {last, Bin, FileSize} | {error, {Code, Text}}</name>
-      <fsummary>Read a chunk from the file</fsummary>
+      <name>Module:read(State) -> {more, Bin, NewState} | {last, Bin, FileSize} | {error, {Code, Text}}</name>
+      <fsummary>Reads a chunk from the file.</fsummary>
       <type>
         <v>State = NewState = term()</v>
         <v>Bin = binary()</v>
@@ -551,13 +560,13 @@
         <v>Text = string()</v>
       </type>
       <desc>
-        <p>Read a chunk from the file.</p>
+        <p>Reads a chunk from the file.</p>
         <p>The callback function is expected to close
 	the file when the last file chunk is
-	encountered. When an error is encountered
+	encountered. When an error is encountered,
 	the callback function is expected to clean
 	up after the aborted file transfer, such as
-	closing open file descriptors etc. In both
+	closing open file descriptors, and so on. In both
 	cases there will be no more calls to any of
 	the callback functions.</p>
     
@@ -566,8 +575,8 @@
     </func>
 
     <func>
-      <name>write(Bin, State) -> {more, NewState} | {last, FileSize} | {error, {Code, Text}}</name>
-      <fsummary>Write a chunk to the file</fsummary>
+      <name>Module:write(Bin, State) -> {more, NewState} | {last, FileSize} | {error, {Code, Text}}</name>
+      <fsummary>Writes a chunk to the file.</fsummary>
       <type>
         <v>Bin = binary()</v>
         <v>State = NewState = term()</v>
@@ -578,99 +587,75 @@
         <v>Text = string()</v>
       </type>
       <desc>
-        <p>Write a chunk to the file.</p>
+        <p>Writes a chunk to the file.</p>
         <p>The callback function is expected to close
 	the file when the last file chunk is
-	encountered. When an error is encountered
+	encountered. When an error is encountered,
 	the callback function is expected to clean
 	up after the aborted file transfer, such as
-	closing open file descriptors etc. In both
+	closing open file descriptors, and so on. In both
 	cases there will be no more calls to any of
 	the callback functions.</p>
     
 	<marker id="abort"></marker>
       </desc>
     </func>
-
-    <func>
-      <name>abort(Code, Text, State) -> ok</name>
-      <fsummary>Abort the file transfer</fsummary>
-      <type>
-        <v>Code = undef | enoent | eacces | enospc</v>
-        <v>&nbsp;&nbsp;| badop | eexist | baduser | badopt</v>
-        <v>&nbsp;&nbsp;| int()</v>
-        <v>Text = string()</v>
-        <v>State = term()</v>
-      </type>
-      <desc>
-        <p>Invoked when the file transfer is aborted.</p>
-        <p>The callback function is expected to clean
-	up its used resources after the aborted file
-	transfer, such as closing open file
-	descriptors etc. The function will not be
-	invoked if any of the other callback
-	functions returns an error, as it is
-	expected that they already have cleaned up
-	the necessary resources. It will however be
-	invoked if the functions fails (crashes).</p>
-      </desc>
-    </func>
   </funcs>
   
   <section>
     <marker id="tftp_logger"></marker>
     <title>LOGGER FUNCTIONS</title>
     
-    <p>A <c>tftp_logger</c> callback module should be implemented as a
-    <c>tftp_logger</c> behavior and export the functions listed below.</p>
+    <p>A <c>tftp_logger</c> callback module is to be implemented as a
+    <c>tftp_logger</c> behavior and export the following functions:</p>
     
     <marker id="error_msg"></marker>
     </section>
 
   <funcs>
     <func>
-      <name>error_msg(Format, Data) -> ok | exit(Reason)</name>
-      <fsummary>Log an error message</fsummary>
+      <name>Logger:error_msg(Format, Data) -> ok | exit(Reason)</name>
+      <fsummary>Logs an error message.</fsummary>
       <type>
         <v>Format = string()</v>
         <v>Data = [term()]</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-	<p>Log an error message. 
-	See <c>error_logger:error_msg/2 for details.</c> </p>
+	<p>Logs an error message. 
+	See <c>error_logger:error_msg/2</c> for details.</p>
 	
 	<marker id="warning_msg"></marker>
       </desc>
     </func>
 
     <func>
-      <name>warning_msg(Format, Data) -> ok | exit(Reason)</name>
-      <fsummary>Log an error message</fsummary>
+      <name>Logger:info_msg(Format, Data) -> ok | exit(Reason)</name>
+      <fsummary>Logs an info message.</fsummary>
       <type>
         <v>Format = string()</v>
         <v>Data = [term()]</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-        <p>Log a warning message. 
-	See <c>error_logger:warning_msg/2 for details.</c> </p>
-	
-	<marker id="info_msg"></marker>
+        <p>Logs an info message. 
+	See <c>error_logger:info_msg/2</c>  for details.</p>
       </desc>
     </func>
-
+    
     <func>
-      <name>info_msg(Format, Data) -> ok | exit(Reason)</name>
-      <fsummary>Log an error message</fsummary>
+      <name>Logger:warning_msg(Format, Data) -> ok | exit(Reason)</name>
+      <fsummary>Logs a warning message.</fsummary>
       <type>
         <v>Format = string()</v>
         <v>Data = [term()]</v>
         <v>Reason = term()</v>
       </type>
       <desc>
-        <p>Log an info message. 
-	See <c>error_logger:info_msg/2 for details.</c> </p>
+        <p>Logs a warning message. 
+	See <c>error_logger:warning_msg/2</c> for details.</p>
+	
+	<marker id="info_msg"></marker>
       </desc>
     </func>
   </funcs>