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