Started implementing protocol version 1.1 and narrowing down

[silc.git] / doc / draft-riikonen-silc-pp-05.nroff

diff --git a/doc/draft-riikonen-silc-pp-05.nroff b/doc/draft-riikonen-silc-pp-05.nroff
index c8a5a9082ddfd15231744edcfadc2c97cf501e49..31b557d768cd9b1271cda40e125e821f5107e0cd 100644 (file)
--- a/doc/draft-riikonen-silc-pp-05.nroff
+++ b/doc/draft-riikonen-silc-pp-05.nroff
@@ -1295,12 +1295,13 @@ Also, all ID's sent in arguments are sent inside ID Payload.
       receiving the packet distributes this type to the local clients
       on the channel and broadcast it to the network.
 
-      Max Arguments:  2
+      Max Arguments:  3
           Arguments:  (1) <Old Client ID>  (2) <New Client ID>
+                      (3) <nickname>
 
       The <Old Client ID> is the old ID of the client which changed
       the nickname.  The <New Client ID> is the new ID generated by
-      the change of the nickname.
+      the change of the nickname.  The <nickname> is the new nickname.
 
 
 7     SILC_NOTIFY_TYPE_CMODE_CHANGE
@@ -1415,12 +1416,13 @@ Also, all ID's sent in arguments are sent inside ID Payload.
       or server receiving the packet distributes this type to the local
       clients on the channel and broadcast it to the network.
 
-      Max Arguments:  2
-          Arguments:  (1) <Client ID>  (2) [<comment>]
+      Max Arguments:  3
+          Arguments:  (1) <Client ID>           (2) [<comment>]
+                      (3) <Killer's Client ID>
 
       The <Client ID> is the client which was killed from the network.
       The killer may have set the <comment> to indicate the reason for
-      the killing.
+      the killing.  The <Killer's Client ID> is the killer.
 
 
 14    SILC_NOTIFY_TYPE_UMODE_CHANGE
@@ -1532,7 +1534,7 @@ represents the Channel Message Payload.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|            Flags              |         Message Length        |
+|        Message  Flags         |         Message Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                         Message Data                          ~
@@ -1559,11 +1561,11 @@ Figure 13:  Channel Message Payload
 
 
 .in 6
-o Flags (2 bytes) - Includes the flags of the channel
-  messages.  The flags can indicate a reason or purpose
-  for the channel message.  Note that the Private Message
-  Payload use these same flags for the same purpose.  The
-  following flags are defined:
+o Message Flags (2 bytes) - Includes the Message Flags of
+  the channel messages.  The flags can indicate a reason or
+  purpose for the channel message.  Note that the Private
+  Message Payload use these same Message Flags for the same
+  purpose. The following Message Flags are defined:
 
   0x0000  SILC_MESSAGE_FLAG_NONE
 
@@ -1604,11 +1606,26 @@ o Flags (2 bytes) - Includes the flags of the channel
           of the signing process and any associated payloads
           of this flag.
 
-  0x0040 - 0x0200 RESERVED
+  0x0040  SILC_MESSAGE_FLAG_REPLY
+
+          This is a generic reply flag to send a reply to
+          previously received request.  A separate document
+          should define any payloads associated to this flag.
+
+  0x0080  SILC_MESSAGE_FLAG_DATA
+
+          This is a generic data flag, indicating that the
+          message includes some data which can be interpreted
+          in a specific way.  Using this flag any kind of data
+          can be delivered inside message payload.  A separate
+          document should define how this flag is interpreted
+          and define any associated payloads.
+
+  0x0100 - 0x0800 RESERVED
 
           Reserved for future flags
 
-  0x0400 - 0x8000 PRIVATE RANGE
+  0x1000 - 0x8000 PRIVATE RANGE
 
           Private range for free use.
 
@@ -1777,7 +1794,7 @@ diagram represents the Private Message Payload.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|            Flags              |      Message Data Length      |
+|         Message Flags         |      Message Data Length      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                          Message Data                         ~
@@ -1794,10 +1811,10 @@ Figure 15:  Private Message Payload
 
 
 .in 6
-o Flags (2 bytes) - This field includes the flags of the
-  private message.  They can indicate a different reason or
-  purpose for the private message.  See the section 2.3.9
-  Channel Message Payload for defined flags.  Note that
+o Message Flags (2 bytes) - This field includes the Message
+  Flags of the private message.  They can indicate a different
+  reason or purpose for the private message.  See the section
+  2.3.9 Channel Message Payload for defined flags.  Note that
   the Channel Message Payload use the same flags for the
   same purpose.
 
@@ -2688,8 +2705,8 @@ directly connected to the server.
 Routers form a ring in the SILC network.  However, routers may have other
 direct connections to other routers in the network too.  This can cause
 interesting routing problems in the network.  Since the network is a ring,
-the packets usually should be routed into counter clock-wise direction,
-or if it cannot be used then always clock-wise (primary route) direction.
+the packets usually should be routed into clock-wise direction, or if it 
+cannot be used then always counter clock-wise (primary route) direction.
 Problems may arise when a faster direct route exists and router is routing
 a channel message.  Currently channel messages must be routed either
 in upstream or downstream, they cannot be routed to other direct routes.
@@ -2814,6 +2831,6 @@ Snellmanninkatu 34 A 15
 70100 Kuopio
 Finland
 
-EMail: priikone@silcnet.org
+EMail: priikone@iki.fi
 
 This Internet-Draft expires XXX