[Nym3-commit] r371 - trunk/nymbaron/doc

[laurent at conuropsis.org]

Author: laurent
Date: 2005-10-31 22:45:59 +0100 (Mon, 31 Oct 2005)
New Revision: 371

Modified:
   trunk/nymbaron/doc/nymbaron.xml
Log:
Various formatting and language issues.


Modified: trunk/nymbaron/doc/nymbaron.xml
===================================================================
--- trunk/nymbaron/doc/nymbaron.xml	2005-10-31 17:07:18 UTC (rev 370)
+++ trunk/nymbaron/doc/nymbaron.xml	2005-10-31 21:45:59 UTC (rev 371)
@@ -47,24 +47,39 @@
     <para>
     Send an account creation request at specified server. If options are not all
     provided, nymbaron will ask interactively for the lacking information. The
-    user has to provide:
-	- a local account identifier.
-	- the address of the nymserver she wants to register her account to.
-	- a list of nyms, that is to say anonymous usernames. The server will
-	choose among them the first free name and attribute it to the user.
-	- a return address, the email address where the packet destined to the
-	nymholder will be returned
-    This information can also be provided through this command option.
+    user has to provide:</para>
+    <itemizedlist>
+    <listitem><para>a local account identifier.</para></listitem>
+    <listitem><para>
+	      the address of the nymserver she wants to register her
+	      account to.
+	      </para>
+    </listitem>
+    <listitem><para>
+	      a list of nyms, that is to say anonymous usernames. The server
+	      will choose among them the first free name and attribute it to
+	      the user.
+	      </para>
+    </listitem>
+    <listitem><para>
+	      a return address, that is, the email address where the
+	      packets destined to the nymholder will be returned.
+	      </para>
+    </listitem>
+    </itemizedlist>
+    <para>
+    This information can also be provided as command line options.
     </para>
     <para>
-    Additionnaly, the user will be prompted for his passphrase to unlock her
-    private keyring. This is necessary to protect the private keys generated for
-    her account in her private keyring. If the keyring doesn't exist yet, it
-    will be created and a password will be asked to protect it.
+    Additionally, the user will be prompted for his passphrase to
+    unlock her private keyring. This is necessary to protect the
+    private keys generated for her account in her private keyring. If
+    the keyring doesn't exist yet, it will be created and a password
+    will be asked to protect it.
     </para>
     <para>
     When this command returns, data for this account are stored in the local
-    file system and registration messages were sent to the nymserver. The user
+    file system and registration messages are sent to the nymserver. The user
     can interrupt the creation of an account when by striking Ctrl-C when
     prompted for information.
     </para>
@@ -75,9 +90,10 @@
     <term><command>send</command></term>
     <listitem>
     <para>
-    Send an email message through a nymserver. If the account from which the
+    Send an email message through a nymserver.
+    <!-- If the account from which the
     user wants to send a message from isn't designed by the appropriate option,
-    returns without doing anything.
+    returns without doing anything. -->
     </para>
     <para>
     The message to be sent is taken from a file pointed by the appropriate
@@ -101,7 +117,7 @@
     <para>
 	In the nymserver protocol, the surbs, single-use reply blocks, are
 	potentially a scarce resource. The protocol design takes this into
-	account : instead of sending each message addressed to a nym directly to
+	account: instead of sending each message addressed to a nym directly to
 	the nymholder, it generates summaries of the messages. The priority is
 	given to provide the nymholder with some information on every message he
 	receives. She will then request explicitely the retrieval of the message
@@ -110,7 +126,7 @@
     <para>
 	A synopsis actually contains some basic information about a message :
 	its mid, its order of arrival on the server, truncated RFC-822 headers
-	and the first characters of the body.
+	and the first few characters of the body.
     </para>
     </listitem>
 </varlistentry>
@@ -153,12 +169,12 @@
     <para>
 	Process returning server messages. The account must be precised by
 	the user, either by the account name or by an idtag. The location of the
-	message is given by the approprite option.
+	message is given by the appropriate option.
     </para>
     <para>
 	The message must already have been decrypted and reassembled by
 	mixminion. The mixminion headers must have been removed as well. If you
-	do not understand this lines, you probably want to use mprocess.
+	do not understand these lines, you probably want to use mprocess.
     </para>
     </listitem>
 </varlistentry>
@@ -166,13 +182,12 @@
     <term><command>mprocess</command></term>
     <listitem>
     <para>
-	Process returning minion messages. The location of the message is given
-	by the approprite option.
+	Process returning minion messages.
     </para>
     <para>
 	This is the command that is used to process a message received from the
 	mixminion network. It will try to reassemble mixminion packets by
-	calling mixminion, and, if successful, will determine the
+	calling mixminion and, if successful, will determine the
 	account the message was addressed to and process it.
     </para>
     </listitem>
@@ -230,7 +245,7 @@
 	The account must be precised by the user.
     </para>
     <para>
-	Because of the lack of fiability insurance in the mixminion network, in
+	Because of the lack of reliability in the mixminion network, in
 	order to keep track of command messages that were sent but not
 	acknowledged and to be able to resend those messages, the sent command
 	messages are recorded in a local journal. This command enables the user
@@ -285,11 +300,12 @@
 	yet been acknowledged.
     </para>
     <para>
-	The mixminion network doesn't garante the fiability of the
-	transmissions. The nymserver protocol takes this into account by
-	providing acknowledgement by the server of received command messages
-	from the client. This command enables the user to resend already sent
-	commands which weren't acknowledged by the server.
+	The mixminion network doesn't garante the reliability of the
+	transmissions. The nymserver protocol takes this into account
+	by providing acknowledgement by the server of received command
+	messages from the client. This command enables the user to
+	resend already sent commands which weren't acknowledged by the
+	server.
     </para>
     </listitem>
 </varlistentry>
@@ -337,9 +353,9 @@
     </para>
     <para>
 	The user may want to remove items from the journal without waiting for
-	the server to acknoledge them, either because she doesn't want to resend
-	a command or because she knows the server received the command and that
-	the acknowledgement was lost.
+	the server to acknowledge them, either because she doesn't
+	want to resend a command or because she knows the server
+	received the command and that the acknowledgement was lost.
     </para>
     <para>
 	Note that after a deletion of journal item, the index designing sequence
@@ -452,7 +468,7 @@
 
 <refsect1><title>AUTHORS</title>
 <para>
-    Laurent Fousse <email>laurent at komite.net</email> and Jean-René
+    Laurent Fousse <email>laurent at komite.net</email> and Jean-René
     Reinhard
     <email>jr at komite.net</email>.
     <ulink
@@ -461,7 +477,7 @@
 </refsect1>
 <refsect1><title>COPYRIGHT</title>
 <para>
-Copyright © 2004,2005 Jean-René Reinhard
+Copyright © 2004,2005 Jean-René Reinhard
 <email>jr at komite.net</email>
 and Laurent Fousse <email>laurent at komite.net</email>.
 </para>