Added SILC Thread Queue API

[crypto.git] / doc / draft-riikonen-silc-commands-04.nroff

diff --git a/doc/draft-riikonen-silc-commands-04.nroff b/doc/draft-riikonen-silc-commands-04.nroff
index 8e0e17cc892f25ad75aecb9ef9407f1eeb12b374..562966c302607a69ebf5e1b8a2a798df6c94320f 100644 (file)
--- a/doc/draft-riikonen-silc-commands-04.nroff
+++ b/doc/draft-riikonen-silc-commands-04.nroff
@@ -301,7 +301,7 @@ List of all defined commands in SILC follows.
 
         The command replies include the Client ID of the nickname,
         nickname and server name, user name and host name and user's real
-        name.  Client SHOULD process these replies only after the last
+        name.  Client should process these replies only after the last
         reply has been received with the STATUS_LIST_END status.  If the
         <count> option were defined in the query there will be only
         <count> many replies from the server.
@@ -399,7 +399,7 @@ List of all defined commands in SILC follows.
 
         Identify command is used to query information about an entity by
         the entity's name or ID.  This command can be used to query
-        information about clients, server and channels.
+        information about clients, servers and channels.
 
         The query may find multiple matching entities.  The <count> option
         may be given to narrow down the number of accepted results.  If
@@ -420,8 +420,8 @@ List of all defined commands in SILC follows.
 
         Implementations may not want to give interface access to this
         command as it is hardly a command that would be used by an end
-        user.  However, it must be implemented as it is used with private
-        message sending.
+        user.  However, it must be implemented as it is most likely used
+        with private message sending.
 
         The IDENTIFY command MUST be always sent to the router by server
         so that all users are searched.  However, server MUST still search
@@ -483,8 +483,8 @@ List of all defined commands in SILC follows.
         When nickname is changed new Client ID is generated.  Server MUST
         distribute SILC_NOTIFY_TYPE_NICK_CHANGE to local clients on the
         channels (if any) the client is joined on.  Then it MUST send
-        SILC_PACKET_REPLACE_ID to its primary route to replace the old
-        Client ID with the new one.
+        SILC_NOTIFY_TYPE_NICK_CHANGE notify  to its primary route to 
+        notify about nickname and Client ID change.
 
         Reply messages to the command:
 
@@ -492,7 +492,7 @@ List of all defined commands in SILC follows.
             Arguments:  (1) <Status Payload>  (2) <New ID Payload>
                         (3) <nickname>
 
-        This command is replied always with New ID Payload that is
+        This command replies always with <New ID Payload> that is
         generated by the server every time user changes their nickname.
         Client receiving this payload MUST start using the received
         Client ID as its current valid Client ID.  The New ID Payload
@@ -1288,9 +1288,8 @@ List of all defined commands in SILC follows.
               channel key that even servers do not know.  Naturally,
               this requires that every client on the channel knows
               the key before hand (it is considered to be pre-shared-
-              key).  The key material is RECOMMENDED to be processed
-              as stated in the [SILC3] in the section Processing the
-              Key Material.
+              key).  The key material SHOULD be processed as stated
+              in the [SILC3] in the section Processing the Key Material.
 
               As it is local setting it is possible to have several
               private channel keys on one channel.  In this case several
@@ -1409,7 +1408,7 @@ List of all defined commands in SILC follows.
 
               If this mode is already set but the <founder pubkey> is
               different the new key will replace the old founder key and
-              the new key is distribute in the network with the
+              the new key is distributed in the network with the
               SILC_NOTIFY_TYPE_CMODE_CHANGE notify.  Only the original
               founder may set this mode multiple times and the client
               MUST have SILC_CUMODE_FOUNDER mode on the channel.
@@ -1419,7 +1418,8 @@ List of all defined commands in SILC follows.
               mode is set the channel MUST NOT be destroyed.  The founder
               can reclaim the founder mode back on these empty channels
               at any time.  Implementations MAY limit the number of how
-              many channels a user can own.
+              many channels a user can own and how long they remain
+              persistent.
 
               Typical implementation would use [+|-]f on user interface
               to set/unset this mode.
@@ -1518,7 +1518,7 @@ List of all defined commands in SILC follows.
               been set, the client can claim channel founder privileges
               by providing the <auth payload> that the server will use
               to authenticate the client.  The public key that server will
-              use to verify the <auth payload> MUST the same public key
+              use to verify the <auth payload> MUST be the same public key
               that was saved when the SILC_CMODE_FOUNDER_AUTH channel
               mode was set.  The client MAY remove this mode at any time.
 
@@ -1893,9 +1893,9 @@ List of all defined commands in SILC follows.
         and with list of user modes on the channel.
 
         If the requested channel is a private or secret channel, this
-        command MUST NOT send the list of users, but error is returned
-        to the sender, except if the sender is on the channel, or the
-        sender is server.
+        command MUST NOT send the list of users, except if the sender is 
+        on the channel, or the sender is a server.  Otherwise, error is
+        returned to the sender.
 
         Reply messages to the command: