The following list of currently defined notify types. The format for
notify arguments is same as in SILC commands described in [SILC4].
-Also, all ID's sent in arguments are sent inside ID Payload.
+Note that all ID's sent in arguments are sent inside ID Payload. Also
+note that all passphrases that may be sent inside arguments MUST be
+UTF-8 [RFC2279] encoded.
.in 6
0 SILC_NOTIFY_TYPE_NONE
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
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
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.
other parts of the packet.
o MAC (variable length) - The MAC computed from the
- Message Length, Message Data, Padding Length and Padding
- fields. This protects the integrity of the plaintext
- channel message. The receiver can verify from the MAC
- whether the message decrypted correctly. Also, if more than
- one private key has been set for the channel, the receiver
- can verify which of the keys decrypted the message
+ Message Length, Message Data, Padding Length, Padding and
+ Initial Vector fields. This protects the integrity of the
+ plaintext channel message. The receiver can verify from
+ the MAC whether the message decrypted correctly. Also, if
+ more than one private key has been set for the channel, the
+ receiver can verify which of the keys decrypted the message
correctly. Note that, this field is encrypted and MUST
be added to the padding calculation.
.ti 0
2.3.12 Private Message Key Payload
-This payload is used to send key from client to another client that
-is going to be used to protect the private messages between these
-two clients. If this payload is not sent normal session key
-established by the SILC Key Exchange Protocol is used to protect
-the private messages.
+This payload is optional and can be used to send private message
+key between two clients in the network. The packet is secured with
+normal session keys. By default private messages are encrypted
+with session keys, and with this payload it is possible to set
+private key for private message encryption between two clients.
+
+The receiver of this payload SHOULD verify for example from user
+whether user wants to receive private message key. Note that there
+are other, more secure ways of exchanging private message keys in
+the SILC network. Instead of sending this payload it is possible to
+negotiate the private message key with SKE protocol using the Key
+Agreement payload directly peer to peer.
This payload may only be sent by client to another client. Server
MUST NOT send this payload at any time. After sending this payload
[SFTP] Ylonen T., and Lehtinen S., "Secure Shell File Transfer
Protocol", Internet Draft, March 2001.
+[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
.ti 0
5 Author's Address