1 .pl 10.0i
2 .po 0
3 .ll 7.2i
4 .lt 7.2i
5 .nr LL 7.2i
6 .nr LT 7.2i
7 .ds LF Riikonen
8 .ds RF FORMFEED[Page %]
9 .ds CF
10 .ds LH Internet Draft
11 .ds RH 15 May 2002
12 .ds CH
13 .na
14 .hy 0
15 .in 0
16 .nf
17 Network Working Group P. Riikonen
18 Internet-Draft
19 draft-riikonen-silc-commands-03.txt 15 May 2002
20 Expires: 15 November 2002
21
22 .in 3
23
24 .ce 2
25 SILC Commands
26 <draft-riikonen-silc-commands-03.txt>
27
28 .ti 0
29 Status of this Memo
30
31 This document is an Internet-Draft and is in full conformance with
32 all provisions of Section 10 of RFC 2026. Internet-Drafts are
33 working documents of the Internet Engineering Task Force (IETF), its
34 areas, and its working groups. Note that other groups may also
35 distribute working documents as Internet-Drafts.
36
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
41
42 The list of current Internet-Drafts can be accessed at
43 http://www.ietf.org/ietf/1id-abstracts.txt
44
45 The list of Internet-Draft Shadow Directories can be accessed at
46 http://www.ietf.org/shadow.html
47
48 The distribution of this memo is unlimited.
49
50
51 .ti 0
52 Abstract
53
54 This memo describes the commands used in the Secure Internet Live
55 Conferencing (SILC) protocol, specified in the Secure Internet Live
56 Conferencing, Protocol Specification Internet Draft [SILC1]. The
57 SILC Commands are very important part of the SILC protocol. Usually
58 the commands are used by SILC clients to manage the SILC session, but
59 also SILC servers may use the commands. This memo specifies detailed
60 command messages and command reply messages.
61
62
63
64
65
66
67
68
69 .ti 0
70 Table of Contents
71
72 .nf
73 1 Introduction .................................................. 2
74 1.1 Requirements Terminology .................................. 2
75 2 SILC Commands ................................................. 2
76 2.1 SILC Commands Syntax ...................................... 2
77 2.2 SILC Commands List ........................................ 4
78 2.3 SILC Command Status Payload ............................... 40
79 3 SILC Status Types ............................................. 41
80 4 Security Considerations ....................................... 47
81 5 References .................................................... 47
82 6 Author's Address .............................................. 49
83 Appendix A ...................................................... 49
84
85
86 .ti 0
87 1. Introduction
88
89 This document describes the commands used in the Secure Internet Live
90 Conferencing (SILC) protocol, specified in the Secure Internet Live
91 Conferencing, Protocol Specification Internet Draft [SILC1]. This
92 document specifies detailed command messages and command reply messages.
93
94 Commands are very important part on SILC network especially for client
95 which uses commands to operate on the SILC network. Commands are used
96 to set nickname, join to channel, change modes and many other things.
97
98 See the [SILC1] for the requirements and the restrictions for the usage
99 of the SILC commands. The [SILC2] defines the command packet type and
100 the Command Payload which is actually used to deliver the commands and
101 command reply messages.
102
103
104 .ti 0
105 1.1 Requirements Terminology
106
107 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
108 MAY, and OPTIONAL, when they appear in this document, are to be
109 interpreted as described in [RFC2119].
110
111
112 .ti 0
113 2 SILC Commands
114
115 .ti 0
116 2.1 SILC Commands Syntax
117
118 This section briefly describes the syntax of the command notions
119 in this document. Every field in command is separated from each
120 other by whitespaces (` ') indicating that each field is independent
121 argument and each argument MUST have own Command Argument Payload.
122 The number of maximum arguments are defined with each command
123 separately. The Command Argument Payload is described in [SILC2].
124
125 Every command defines specific number for each argument. Currently,
126 they are defined in ascending order; first argument has number one
127 (1), second has number two (2) and so on. This number is set into the
128 Argument Type field in the Command Argument Payload. This makes it
129 possible to send the arguments in free order as the number MUST be
130 used to identify the type of the argument. This makes is it also
131 possible to have multiple optional arguments in commands and in
132 command replies. The number of argument is marked in parentheses
133 before the actual argument.
134
135
136
137 .in 6
138 Example: Arguments: (1) <nickname> (2) <username@host>
139 .in 3
140
141
142 Every command replies with Status Payload. This payload tells the
143 sender of the command whether the command was completed successfully or
144 whether there was an error. If error occurred the payload includes the
145 error type. In the next section the Status Payload is not described
146 as it is common to all commands and has been described here. Commands
147 MAY reply with other arguments as well. These arguments are command
148 specific and are described in the next section.
149
150 Example command:
151 .in 6
152
153 EXAMPLE_COMMAND
154
155 .in 8
156 Max Arguments: 3
157 Arguments: (1) <nickname>[@<server>] (2) <message>
158 (3) [<count>]
159
160 The command has maximum of 3 arguments. However, only first
161 and second arguments are mandatory.
162
163 First argument <nickname> is mandatory but may have optional
164 <nickname@server> format as well. Second argument is mandatory
165 <message> argument. Third argument is optional <count> argument.
166
167 The numbers in parentheses are the argument specific numbers
168 that specify the type of the argument in Command Argument Payload.
169 The receiver always knows that, say, argument number two (2) is
170 <message> argument, regardless of the ordering of the arguments in
171 the Command Payload.
172
173 Reply messages to the command:
174
175 Max Arguments: 4
176 Arguments: (1) <Status Payload> (2) [<channel list>]
177 (3) <idle time> (4) [<away message>]
178
179 This command may reply with maximum of 4 arguments. However,
180 only the first and third arguments are mandatory. The numbers
181 in the parentheses have the same meaning as in the upper
182 command sending specification.
183
184 Every command reply with <Status Payload>, it is mandatory
185 argument for all command replies and for this reason it is not
186 described in the command reply descriptions.
187
188
189
190 Status messages:
191
192 SILC_STATUS_OK
193 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
194 SILC_STATUS_ERR_NO_SUCH_NICK
195
196 Every command reply also defines set of status message that it
197 may return inside the <Status Payload>. All status messages
198 are defined in the section 2.3 SILC Command Status Payload
199
200 .in 3
201 Every command that has some kind of ID as argument (for example
202 <Client ID>) are actually ID Payloads, defined in [SILC2] that includes
203 the type of the ID, length of the ID and the actual ID data. This
204 way variable length ID's can be sent as arguments. Also note that
205 all passphrases that may be sent in commands MUST be UTF-8 [RFC2279]
206 encoded.
207
208
209 .ti 0
210 2.2 SILC Commands List
211
212 This section lists all SILC commands, however, it is expected that a
213 implementation and especially client implementation has many more
214 commands that has only local affect. These commands are official
215 SILC commands that has both client and server sides and cannot be
216 characterized as local commands.
217
218 List of all defined commands in SILC follows.
219
220 .in 0
221 0 SILC_COMMAND_NONE
222
223 None. This is reserved command and MUST NOT be sent.
224
225
226 1 SILC_COMMAND_WHOIS
227
228 Max Arguments: 256
229 Arguments: (1) [<nickname>[@<server>]] (2) [<count>]
230 (3) [<Requested Attributes>] (4) [<Client ID>]
231 (n) [...]
232
233 Whois command is used to query various information about specific
234 user. The user may be requested by their nickname and server name.
235 The query may find multiple matching users as there are no unique
236 nicknames in the SILC. The <count> option may be given to narrow
237 down the number of accepted results. If this is not defined there
238 are no limit of accepted results. The query may also be narrowed
239 down by defining the server name of the nickname. The <count> is
240 32 bit MSB first order integer.
241
242 It is also possible to search the user by Client ID. If the
243 <Client ID> is provided server MUST use it as the search value
244 instead of the <nickname>. One of the arguments MUST be given.
245 It is also possible to define multiple Client ID's to search
246 multiple users sending only one WHOIS command. In this case the
247 Client ID's are appended as normal arguments.
248
249 To prevent miss-use of this command wildcards in the nickname
250 or in the server name are not permitted. It is not allowed
251 to request all users on some server. The WHOIS requests MUST
252 be based on explicit nickname request.
253
254 The WHOIS request MUST be always sent to the router by server
255 so that all users are searched. However, the server still MUST
256 search its locally connected clients. The router MUST send
257 this command to the server which owns the requested client, if
258 the router is unable to provide all mandatory information about
259 the client. That server MUST reply to the command. Server MUST
260 NOT send whois replies to the client until it has received the
261 reply from its router.
262
263 The <Requested Attributes> is defined in [ATTRS] and can be used
264 to request various information about the client. See Appendix A
265 for definition of using these attributes in SILC.
266
267 Reply messages to the command:
268
269 Max Arguments: 11
270 Arguments: (1) <Status Payload> (2) <Client ID>
271 (3) <nickname>[@<server>] (4) <username@host>
272 (5) <real name> (6) [<Channel Payload
273 list>]
274 (7) [<user mode>] (8) [<idle time>]
275 (9) [<fingerprint>] (10) <channel user
276 mode list>
277 (11) [<Attributes>]
278
279
280 This command may reply with several command reply messages to
281 form a list of results. In this case the status payload will
282 include STATUS_LIST_START status in the first reply and
283 STATUS_LIST_END in the last reply to indicate the end of the
284 list. If there are only one reply the status is set to normal
285 STATUS_OK. If multiple Client IDs was requested then each found
286 and unfound client must cause successful or error reply,
287 respectively.
288
289 The command replies include the Client ID of the nickname,
290 nickname and server name, user name and host name and user's real
291 name. Client SHOULD process these replies only after the last
292 reply has been received with the STATUS_LIST_END status. If the
293 <count> option were defined in the query there will be only
294 <count> many replies from the server.
295
296 The server returns the list of channels if the client has
297 joined channels. In this case the list is list of Channel
298 Payloads. The Mode Mask in the Channel Payload is the channel's
299 mode. The list is encoded by adding the Channel Payloads one
300 after the other. Private and secret channels MUST NOT be sent,
301 except if the sender of this command is on those channels, or
302 the sender is server. The <channel user mode list> MUST also
303 be sent if client is joined channels. This list includes 32 bit
304 MSB first order values one after the other and each indicate
305 the user's mode on a channel. The order of these values MUST
306 be same as the channel order in the <Channel Payload list>.
307
308 The server also returns client's user mode, idle time, and the
309 fingerprint of the client's public key. The <fingerprint> is the
310 binary hash digest of the public key. The fingerprint MUST NOT
311 be sent if the server has not verified the proof of possession of
312 the corresponding private key. Server can do this during the
313 SILC Key Exchange protocol. The <fingerprint> is SHA1 digest.
314
315 The <Attributes> is the reply to the <Requested Attributes>.
316 See the Appendix A for more information.
317
318 Status messages:
319
320 SILC_STATUS_OK
321 SILC_STATUS_LIST_START
322 SILC_STATUS_LIST_END
323 SILC_STATUS_ERR_NO_SUCH_NICK
324 SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
325 SILC_STATUS_ERR_WILDCARDS
326 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
327 SILC_STATUS_ERR_TOO_MANY_PARAMS
328
329
330 2 SILC_COMMAND_WHOWAS
331
332 Max Arguments: 2
333 Arguments: (1) <nickname>[@<server>] (2) [<count>]
334
335 Whowas. This command is used to query history information about
336 specific user. The user may be requested by their nickname and
337 server name. The query may find multiple matching users as there
338 are no unique nicknames in the SILC. The <count> option may be
339 given to narrow down the number of accepted results. If this
340 is not defined there are no limit of accepted results. The query
341 may also be narrowed down by defining the server name of the
342 nickname. The <count> is 32 bit MSB first order integer.
343
344 To prevent miss-use of this command wildcards in the nickname
345 or in the server name are not permitted. The WHOWAS requests MUST
346 be based on specific nickname request.
347
348 The WHOWAS request MUST be always sent to the router by server
349 so that all users are searched. However, the server still must
350 search its locally connected clients.
351
352 Reply messages to the command:
353
354 Max Arguments: 5
355 Arguments: (1) <Status Payload> (2) <Client ID>
356 (3) <nickname>[@<server>] (4) <username@host>
357 (5) [<real name>]
358
359 This command may reply with several command reply messages to form
360 a list of results. In this case the status payload will include
361 STATUS_LIST_START status in the first reply and STATUS_LIST_END in
362 the last reply to indicate the end of the list. If there are only
363 one reply the status is set to normal STATUS_OK.
364
365 The command replies with nickname and user name and host name.
366 Every server MUST keep history for some period of time of its
367 locally connected clients.
368
369 Status messages:
370
371 SILC_STATUS_OK
372 SILC_STATUS_LIST_START
373 SILC_STATUS_LIST_END
374 SILC_STATUS_ERR_NO_SUCH_NICK
375 SILC_STATUS_ERR_WILDCARDS
376 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
377 SILC_STATUS_ERR_TOO_MANY_PARAMS
378
379
380 3 SILC_COMMAND_IDENTIFY
381
382 Max Arguments: 256
383 Arguments: (1) [<nickname>[@<server>]] (2) [<server name>]
384 (3) [<channel name>] (4) [<count>]
385 (5) [<ID Payload>] (n) [...]
386
387 Identify command is used to query information about an entity by
388 the entity's name or ID. This command can be used to query
389 information about clients, server and channels.
390
391 The query may find multiple matching entities. The <count> option
392 may be given to narrow down the number of accepted results. If
393 this is not defined there are no limit of accepted results. The
394 <count> is 32 bit MSB first order integer.
395
396 It is also possible to search the entity by its ID. If the
397 <ID Payload> is provided server must use it as the search value
398 instead of the entity's name. One of the arguments must be given.
399 It is also possible to define multiple ID Payloads to search
400 multiple entities sending only one IDENTIFY command. In this case
401 the ID Payloads are appended as normal arguments. The type of the
402 entity is defined by the type of the ID Payload.
403
404 To prevent miss-use of this command wildcards in the names are
405 not permitted. It is not allowed to request for example all users
406 on server.
407
408 Implementations may not want to give interface access to this
409 command as it is hardly a command that would be used by an end
410 user. However, it must be implemented as it is used with private
411 message sending.
412
413 The IDENTIFY command MUST be always sent to the router by server
414 so that all users are searched. However, server MUST still search
415 its locally connected clients.
416
417 Reply messages to the command:
418
419 Max Arguments: 4
420 Arguments: (1) <Status Payload> (2) <ID Payload>
421 (3) [<entity's name>] (4) [<info>]
422
423 This command may reply with several command reply messages to form
424 a list of results. In this case the status payload will include
425 STATUS_LIST_START status in the first reply and STATUS_LIST_END in
426 the last reply to indicate the end of the list. If there are only
427 one reply the status is set to normal STATUS_OK. If multiple Client
428 IDs was requested then each found and unfound client must cause
429 successful or error reply, respectively.
430
431 When querying clients the <entity's name> must include the client's
432 nickname in the following format: nickname[@server]. The
433 <info> must include the client's username and host in the following
434 format: username@host.
435
436 When querying servers the <entity's name> must include the server's
437 full name. The <info> may be omitted.
438
439 When querying channels the <entity's name> must include the
440 channel's name. The <info> may be omitted.
441
442 If the <count> option were defined in the query there will be only
443 <count> many replies from the server.
444
445 Status messages:
446
447 SILC_STATUS_OK
448 SILC_STATUS_LIST_START
449 SILC_STATUS_LIST_END
450 SILC_STATUS_ERR_NO_SUCH_NICK
451 SILC_STATUS_ERR_NO_SUCH_SERVER
452 SILC_STATUS_ERR_NO_SUCH_CHANNEL
453 SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
454 SILC_STATUS_ERR_NO_SUCH_SERVER_ID
455 SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
456 SILC_STATUS_ERR_WILDCARDS
457 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
458 SILC_STATUS_ERR_TOO_MANY_PARAMS
459
460
461 4 SILC_COMMAND_NICK
462
463 Max Arguments: 1
464 Arguments: (1) <nickname>
465
466 Set/change nickname. This command is used to set nickname for
467 user. Nickname MUST NOT include any spaces (` '), non-printable
468 characters, commas (`,') and any wildcard characters.
469
470 When nickname is changed new Client ID is generated. Server MUST
471 distribute SILC_NOTIFY_TYPE_NICK_CHANGE to local clients on the
472 channels (if any) the client is joined on. Then it MUST send
473 SILC_PACKET_REPLACE_ID to its primary route to replace the old
474 Client ID with the new one.
475
476 Reply messages to the command:
477
478 Max Arguments: 3
479 Arguments: (1) <Status Payload> (2) <New ID Payload>
480 (3) <nickname>
481
482 This command is replied always with New ID Payload that is
483 generated by the server every time user changes their nickname.
484 Client receiving this payload MUST start using the received
485 Client ID as its current valid Client ID. The New ID Payload
486 is described in [SILC2]. The <nickname> is the user's new
487 nickname.
488
489 Status messages:
490
491 SILC_STATUS_OK
492 SILC_STATUS_ERR_WILDCARDS
493 SILC_STATUS_ERR_NICKNAME_IN_USE
494 SILC_STATUS_ERR_BAD_NICKNAME
495 SILC_STATUS_ERR_NOT_REGISTERED
496 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
497 SILC_STATUS_ERR_TOO_MANY_PARAMS
498
499
500 5 SILC_COMMAND_LIST
501
502 Max Arguments: 1
503 Arguments: (1) [<Channel ID>]
504
505 The list command is used to list channels and their topics on the
506 current server. If the <Channel ID> parameter is used, only the
507 status of that channel is displayed. Secret channels are not
508 listed at all. Private channels are listed with status indicating
509 that the channel is private. Router MAY reply with all channels
510 it knows about.
511
512 Reply messages to the command:
513
514 Max Arguments: 5
515 Arguments: (1) <Status Payload> (2) <Channel ID>
516 (3) <channel> (4) [<topic>]
517 (5) [<user count>]
518
519 This command may reply with several command reply messages to form
520 a list of results. In this case the status payload will include
521 STATUS_LIST_START status in the first reply and STATUS_LIST_END in
522 the last reply to indicate the end of the list. If there are only
523 one reply the status is set to normal STATUS_OK.
524
525 This command replies with Channel ID, name and the topic of the
526 channel. If the channel is private channel the <topic> SHOULD
527 include the "*private*" string.
528
529 Status messages:
530
531 SILC_STATUS_OK
532 SILC_STATUS_LIST_START
533 SILC_STATUS_LIST_END
534 SILC_STATUS_ERR_WILDCARDS
535 SILC_STATUS_ERR_NOT_REGISTERED
536 SILC_STATUS_ERR_TOO_MANY_PARAMS
537 SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
538 SILC_STATUS_ERR_NO_CHANNEL_ID
539 SILC_STATUS_ERR_NO_SUCH_SERVER
540
541
542 6 SILC_COMMAND_TOPIC
543
544 Max Arguments: 2
545 Arguments: (1) <Channel ID> (2) [<topic>]
546
547 This command is used to change or view the topic of a channel.
548 The topic for channel <Channel ID> is returned if there is no
549 <topic> given. If the <topic> parameter is present, the topic
550 for that channel will be changed, if the channel modes permit
551 this action.
552
553 After setting the topic the server MUST send the notify type
554 SILC_NOTIFY_TYPE_TOPIC_SET to its primary router and then to
555 the channel which topic was changed.
556
557 Reply messages to the command:
558
559 Max Arguments: 2
560 Arguments: (1) <Status Payload> (2) <Channel ID>
561 (3) [<topic>]
562
563 The command may reply with the topic of the channel if it is
564 set.
565
566 Status messages:
567
568 SILC_STATUS_OK
569 SILC_STATUS_ERR_NOT_ON_CHANNEL
570 SILC_STATUS_ERR_WILDCARDS
571 SILC_STATUS_ERR_NOT_REGISTERED
572 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
573 SILC_STATUS_ERR_NO_SUCH_CHANNEL
574 SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
575 SILC_STATUS_ERR_NO_CHANNEL_ID
576 SILC_STATUS_ERR_BAD_CHANNEL_ID
577 SILC_STATUS_ERR_TOO_MANY_PARAMS
578 SILC_STATUS_ERR_NO_CHANNEL_PRIV
579
580
581 7 SILC_COMMAND_INVITE
582
583 Max Arguments: 4
584 Arguments: (1) <Channel ID> (2) [<Client ID>]
585 (3) [<adding client>] (4) [<removing client>]
586
587 This command is used to invite other clients to join to the
588 channel. The <Client ID> argument is the target client's ID that
589 is being invited. The <Channel ID> is the Channel ID of the
590 requested channel. The sender of this command MUST be on the
591 channel. The server MUST also send the notify type
592 SILC_NOTIFY_TYPE_INVITE to its primary router and then to the
593 client indicated by the <Client ID>.
594
595 The <adding client> and <removing client> can be used to add to
596 and remove from the invite list. The format of the <adding client>
597 and <removing client> is as follows:
598
599 [<nickname>[@<server>]!][<username>]@[<hostname>]
600
601 When adding to or removing from the invite list the server MUST
602 send the notify type SILC_NOTIFY_TYPE_INVITE to its primary router
603 and MUST NOT send it to the client which was added to the list.
604 The client which executes this command MUST have at least channel
605 operator privileges to be able to add to or remove from the invite
606 list. The wildcards MAY be used with this command. If adding or
607 removing more than one client then the lists are an comma (`,')
608 separated.
609
610 Note that the <Client ID> provided MUST be resolved into correct
611 nickname and host name and add to the invite list before sending
612 the notify packet.
613
614 When this command is given with only <Channel ID> argument then
615 the command merely returns the invite list of the channel. This
616 command MUST fail if the requested channel does not exist, the
617 requested <Client ID> is already on the channel or if the channel
618 is invite only channel and the caller of this command does not
619 have at least channel operator privileges.
620
621 Reply messages to the command:
622
623 Max Arguments: 3
624 Arguments: (1) <Status Payload> (2) <Channel ID>
625 (3) [<invite list>]
626
627 This command replies with the invite list of the channel if it
628 exists.
629
630 Status messages:
631
632 SILC_STATUS_OK
633 SILC_STATUS_ERR_NOT_REGISTERED
634 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
635 SILC_STATUS_ERR_TOO_MANY_PARAMS
636 SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
637 SILC_STATUS_ERR_NO_CLIENT_ID
638 SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
639 SILC_STATUS_ERR_NO_CHANNEL_ID
640 SILC_STATUS_ERR_NOT_ON_CHANNEL
641 SILC_STATUS_ERR_USER_ON_CHANNEL
642 SILC_STATUS_ERR_NO_CHANNEL_PRIV
643 SILC_STATUS_ERR_RESOURCE_LIMIT
644
645
646 8 SILC_COMMAND_QUIT
647
648 Max Arguments: 1
649 Arguments: (1) [<quit message>]
650
651 This command is used by client to end SILC session. The server
652 must close the connection to a client which sends this command.
653 if <quit message> is given it will be sent to other clients on
654 channel if the client is on channel when quitting.
655
656 Reply messages to the command:
657
658 This command does not reply anything.
659
660
661 9 SILC_COMMAND_KILL
662
663 Max Arguments: 2
664 Arguments: (1) <Client ID> (2) [<comment>]
665
666 This command is used by SILC operators to remove a client from
667 SILC network. The removing has temporary effects and client may
668 reconnect to SILC network. The <Client ID> is the client to be
669 removed from SILC. The <comment> argument may be provided to
670 give to the removed client some information why it was removed
671 from the network.
672
673 When killing a client the router MUST first send notify type
674 SILC_NOTIFY_TYPE_KILLED to all channels the client has joined.
675 The packet MUST NOT be sent to the killed client on the channels.
676 Then, the router MUST send the same notify type to its primary
677 router. Finally, the router MUST send the same notify type
678 directly to the client which was killed.
679
680 Reply messages to the command:
681
682 Max Arguments: 1
683 Arguments: (1) <Status Payload>
684
685 This command replies only with Status Payload.
686
687 Status messages:
688
689 SILC_STATUS_OK
690 SILC_STATUS_ERR_WILDCARDS
691 SILC_STATUS_ERR_NOT_REGISTERED
692 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
693 SILC_STATUS_ERR_TOO_MANY_PARAMS
694 SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
695 SILC_STATUS_ERR_NO_CLIENT_ID
696 SILC_STATUS_ERR_NO_ROUTER_PRIV
697
698
699 10 SILC_COMMAND_INFO
700
701 Max Arguments: 2
702 Arguments: (1) [<server>] (2) [<Server ID>]
703
704 This command is used to fetch various information about a server.
705 If <server> argument is specified the command MUST be sent to
706 the requested server.
707
708 If the <Server ID> is specified the server information if fetched
709 by the provided Server ID. One of the arguments must always be
710 present.
711
712 Reply messages to the command:
713
714 Max Arguments: 4
715 Arguments: (1) <Status Payload> (2) <Server ID>
716 (3) <server name> (4) <string>
717
718 This command replies with the Server ID of the server and a
719 string which tells the information about the server.
720
721 Status messages:
722
723 SILC_STATUS_OK
724 SILC_STATUS_ERR_WILDCARDS
725 SILC_STATUS_ERR_NOT_REGISTERED
726 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
727 SILC_STATUS_ERR_TOO_MANY_PARAMS
728 SILC_STATUS_ERR_NO_SUCH_SERVER
729 SILC_STATUS_ERR_NO_SUCH_SERVER_ID
730 SILC_STATUS_ERR_NO_SERVER_ID
731
732
733 11 SILC_COMMAND_STATS
734
735 Max Arguments: 1
736 Arguments: (1) <Server ID>
737
738 This command is used to fetch various statistical information
739 from the server indicated by <Server ID>, which is the ID of
740 server where sender is connected to. Server receiving this
741 command MAY also send this further to its router for fetching
742 other cell and network wide statistics to accompany the reply.
743
744 Reply messages to the command:
745
746 Max Arguments: 3
747 Arguments: (1) <Status Payload> (2) <Server ID>
748 (3) [<statistics structure>]
749
750 This command replies with the Server ID of the server and
751 optional statistics structure which includes 32 bit MSB first
752 ordered integer values to represent various statistical
753 information. The structure is as follows:
754
755 starttime - time when server was started
756 uptime - uptime of the server
757 my clients - number of locally connected clients
758 my channels - number of locally created channels
759 my server ops - number of local server operators
760 my router ops - number of local router operators
761 cell clients - number of clients in local cell
762 cell channels - number of channels in local cell
763 cell servers - number of servers in local cell
764 clients - number of client in SILC network
765 channels - number of channels in SILC network
766 servers - number of servers in SILC network
767 routers - number of routers in SILC network
768 server ops - number of server operators in SILC network
769 router ops - number of router operators in SILC network
770
771 If some value is unknown it is set to zero (0) value. The
772 "starttime" is the start time of the server, and is seconds
773 since Epoch (POSIX.1). The "uptime" is time difference of
774 current time and "starttime" in the server, and is seconds
775 in value.
776
777 Status messages:
778
779 SILC_STATUS_OK
780 SILC_STATUS_ERR_NOT_REGISTERED
781 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
782 SILC_STATUS_ERR_TOO_MANY_PARAMS
783 SILC_STATUS_ERR_NO_SUCH_SERVER_ID
784 SILC_STATUS_ERR_NO_SUCH_SERVER
785 SILC_STATUS_ERR_NO_SERVER_ID
786
787
788 12 SILC_COMMAND_PING
789
790 Max Arguments: 1
791 Arguments: (1) <Server ID>
792
793 This command is used by client and server to test the communication
794 channel to its server if one suspects that the communication is not
795 working correctly. The <Server ID> is the ID of the server the
796 sender is connected to.
797
798 Reply messages to the command:
799
800 Max Arguments: 1
801 Arguments: (1) <Status Payload>
802
803 This command replies only with Status Payload. Server returns
804 SILC_STATUS_OK in Status Payload if pinging was successful.
805
806
807
808 Status messages:
809
810 SILC_STATUS_OK
811 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
812 SILC_STATUS_ERR_TOO_MANY_PARAMS
813 SILC_STATUS_ERR_NO_SERVER_ID
814 SILC_STATUS_ERR_NO_SUCH_SERVER
815 SILC_STATUS_ERR_NOT_REGISTERED
816
817
818 13 SILC_COMMAND_OPER
819
820 Max Arguments: 2
821 Arguments: (1) <username> (2) <authentication payload>
822
823 This command is used by normal client to obtain server operator
824 privileges on some server or router. Note that router operator
825 has router privileges that supersedes the server operator
826 privileges and this does not obtain those privileges. Client
827 MUST use SILCOPER command to obtain router level privileges.
828
829 The <username> is the username set in the server configurations
830 as operator. The <authentication payload> is the data that the
831 client is authenticated against. It may be passphrase prompted
832 for user on client's screen or it may be public key or certificate
833 authentication data (data signed with private key). The public
834 key that server will use to verify the signature found in the
835 payload should be verified. It is recommended that the public
836 key is saved locally in the server and server would not use
837 any public keys received during the SKE.
838
839 After changing the mode the server MUST send the notify type
840 SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
841
842 Reply messages to the command:
843
844 Max Arguments: 1
845 Arguments: (1) <Status Payload>
846
847 This command replies only with Status Payload.
848
849 Status messages:
850
851 SILC_STATUS_OK
852 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
853 SILC_STATUS_ERR_TOO_MANY_PARAMS
854 SILC_STATUS_ERR_NOT_REGISTERED
855 SILC_STATUS_ERR_AUTH_FAILED
856
857
858 14 SILC_COMMAND_JOIN
859
860 Max Arguments: 6
861 Arguments: (1) <channel> (2) <Client ID>
862 (3) [<passphrase>] (4) [<cipher>]
863 (5) [<hmac>] (6) [<founder auth>]
864
865 Join to channel/create new channel. This command is used to
866 join to a channel. If the channel does not exist the channel is
867 created. If server is normal server this command MUST be sent
868 to router which will create the channel. The channel MAY be
869 protected with passphrase. If this is the case the passphrase
870 MUST be sent along the join command.
871
872 The name of the <channel> MUST NOT include any spaces (` '),
873 non-printable characters, commas (`,') or any wildcard characters.
874
875 The second argument <Client ID> is the Client ID of the client
876 which is joining to the client. When client sends this command
877 to the server the <Client ID> MUST be the client's own ID.
878
879 Cipher to be used to secure the traffic on the channel MAY be
880 requested by sending the name of the requested <cipher>. This
881 is used only if the channel does not exist and is created. If
882 the channel already exists the cipher set previously for the
883 channel will be used to secure the traffic. The computed MACs
884 of the channel message are produced by the default HMAC or by
885 the <hmac> provided for the command.
886
887 The <founder auth> is Authentication Payload providing the
888 authentication for gaining founder privileges on the channel
889 when joining the channel. The client may provide this if it
890 knows that it is the founder of the channel and that the
891 SILC_CMODE_FOUNDER_AUTH mode is set on the channel. The server
892 MUST verify whether the client is able to gain the founder
893 privileges the same way as the client had given the
894 SILC_COMMAND_CUMODE command to gain founder privileges. The
895 client is still able to join the channel even if the founder
896 privileges could not be gained. The hash function used with
897 the <founder payload> MUST be sha1.
898
899 The server MUST check whether the user is allowed to join to
900 the requested channel. Various modes set to the channel affect
901 the ability of the user to join the channel. These conditions
902 are:
903
904 o The user MUST be invited to the channel if the channel
905 is invite-only channel.
906
907 o The Client ID/nickname/username/host name MUST NOT match
908 any active bans.
909
910 o The correct passphrase MUST be provided if passphrase
911 is set to the channel.
912
913 o The user count limit, if set, MUST NOT be reached.
914
915 If the client provided correct <founder auth> payload it can
916 override these conditions, except the condition for the passphrase.
917 The correct passphrase MUST be provided even if <founder auth>
918 payload is provided.
919
920 Reply messages to the command:
921
922 Max Arguments: 14
923 Arguments: (1) <Status Payload> (2) <channel>
924 (3) <Channel ID> (4) <Client ID>
925 (5) <channel mode mask> (6) <created>
926 (7) [<Channel Key Payload>] (8) [<ban list>]
927 (9) [<invite list>] (10) [<topic>]
928 (11) [<hmac>] (12) <list count>
929 (13) <Client ID list> (14) <client mode list>
930
931 This command replies with the channel name requested by the
932 client, channel ID of the channel and topic of the channel
933 if it exists. The <Client ID> is the Client ID which was joined
934 to the channel. It also replies with the channel mode mask
935 which tells all the modes set on the channel. If the
936 channel is created the mode mask is zero (0). If ban mask
937 and/or invite list is set they are sent as well.
938
939 The <list count>, <Client ID list> and <client mode list> are
940 the clients currently on the channel and their modes on the
941 channel. The <Client ID list> is formed by adding the ID Payloads
942 one after the other. The <client mode list> is formed by adding
943 32 bit MSB first order values one after the other.
944
945 Client receives the channel key in the reply message as well
946 inside <Channel Key Payload>.
947
948 Status messages:
949
950 SILC_STATUS_OK
951 SILC_STATUS_ERR_WILDCARDS
952 SILC_STATUS_ERR_NOT_REGISTERED
953 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
954 SILC_STATUS_ERR_TOO_MANY_PARAMS
955 SILC_STATUS_ERR_BAD_PASSWORD
956 SILC_STATUS_ERR_CHANNEL_IS_FULL
957 SILC_STATUS_ERR_NOT_INVITED
958 SILC_STATUS_ERR_BANNED_FROM_CHANNEL
959 SILC_STATUS_ERR_BAD_CHANNEL
960 SILC_STATUS_ERR_USER_ON_CHANNEL
961
962
963 15 SILC_COMMAND_MOTD
964
965 Max Arguments: 1
966 Arguments: (1) <server>
967
968 This command is used to query the Message of the Day of the server.
969
970 Reply messages to the command:
971
972 Max Arguments: 3
973 Arguments: (1) <Status Payload> (2) <Server ID>
974 (3) [<motd>]
975
976 This command replies with the motd message if it exists.
977
978 Status messages:
979
980 SILC_STATUS_OK
981 SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
982 SILC_STATUS_ERR_TOO_MANY_PARAMS
983 SILC_STATUS_ERR_NOT_REGISTERED
984 SILC_STATUS_ERR_NO_SUCH_SERVER
985
986
987 16 SILC_COMMAND_UMODE
988
989 Max Arguments: 2
990 Arguments: (1) <Client ID> (2) [<client mode mask>]
991
992 This command is used by client to set/unset modes for itself.
993 However, there are some modes that the client MUST NOT set itself,
994 but they will be set by server. However, client MAY unset any
995 mode. Modes may be masked together ORing them thus having
996 several modes set. Client MUST keep its client mode mask
997 locally so that the mode setting/unsetting would work without
998 problems. Client may change only its own modes.
999
1000 After changing the mode server MUST send the notify type
1001 SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
1002
1003 The following client modes are defined:
1004
1005 0x00000000 SILC_UMODE_NONE
1006
1007 No specific mode for client. This is the initial
1008 setting when new client is created. The client is
1009 normal client and is present in the network.
1010
1011
1012 0x00000001 SILC_UMODE_SERVER_OPERATOR
1013
1014 Marks the user as server operator. Client MUST NOT
1015 set this mode itself. Server sets this mode to the
1016 client when client attains the server operator
1017 privileges by SILC_COMMAND_OPER command. Client
1018 MAY unset the mode itself.
1019
1020
1021 0x00000002 SILC_UMODE_ROUTER_OPERATOR
1022
1023 Marks the user as router (SILC) operator. Client
1024 MUST NOT set this mode itself. Router sets this mode
1025 to the client when client attains the router operator
1026 privileges by SILC_COMMAND_SILCOPER command. Client
1027 MAY unset the mode itself.
1028
1029
1030 0x00000004 SILC_UMODE_GONE
1031
1032 Marks that the user is not currently present in the
1033 SILC Network. Client MAY set and unset this mode.
1034
1035
1036 0x00000008 SILC_UMODE_INDISPOSED
1037
1038 Marks that the user is currently indisposed and may
1039 not be able to receive any messages, and that user may
1040 not be present in the network. Client MAY set and
1041 unset this mode.
1042
1043
1044 0x00000010 SILC_UMODE_BUSY
1045
1046 Marks that the user is currently busy and may not
1047 want to receive any messages, and that user may not