doc/draft-riikonen-silc-commands-03.nroff

   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 XXX
  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                     XXX
  20 Expires: XXX
  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 ............................... 33
  79 3 SILC Status Types ............................................. 33
  80 4 Security Considerations ....................................... 38
  81 5 References .................................................... 38
  82 6 Author's Address .............................................. 40
  83 Appendix A ...................................................... xx
  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_TOO_MANY_TARGETS
 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
 201 .in 3
 202 Every command that has some kind of ID as argument (for example
 203 <Client ID>) are actually ID Payloads, defined in [SILC2] that includes
 204 the type of the ID, length of the ID and the actual ID data.  This
 205 way variable length ID's can be sent as arguments.  Also note that
 206 all passphrases that may be sent in commands MUST be UTF-8 [RFC2279]
 207 encoded.
 208
 209
 210 .ti 0
 211 2.2 SILC Commands List
 212
 213 This section lists all SILC commands, however, it is expected that a
 214 implementation and especially client implementation has many more
 215 commands that has only local affect.  These commands are official
 216 SILC commands that has both client and server sides and cannot be
 217 characterized as local commands.
 218
 219 List of all defined commands in SILC follows.
 220
 221 .in 0
 222    0    SILC_COMMAND_NONE
 223
 224         None.  This is reserved command and MUST NOT be sent.
 225
 226
 227    1    SILC_COMMAND_WHOIS
 228
 229         Max Arguments:  256
 230             Arguments:  (1) [<nickname>[@<server>]]   (2) [<count>]
 231                         (3) [<Requested Attributes>]  (4) [<Client ID>]
 232                         (n) [...]
 233
 234         Whois command is used to query various information about specific
 235         user.  The user may be requested by their nickname and server name.
 236         The query may find multiple matching users as there are no unique
 237         nicknames in the SILC.  The <count> option may be given to narrow
 238         down the number of accepted results.  If this is not defined there
 239         are no limit of accepted results.  The query may also be narrowed
 240         down by defining the server name of the nickname.  The <count> is
 241         32 bit MSB first order integer.
 242
 243         It is also possible to search the user by Client ID.  If the
 244         <Client ID> is provided server MUST use it as the search value
 245         instead of the <nickname>.  One of the arguments MUST be given.
 246         It is also possible to define multiple Client ID's to search
 247         multiple users sending only one WHOIS command.  In this case the
 248         Client ID's are appended as normal arguments.
 249
 250         To prevent miss-use of this command wildcards in the nickname
 251         or in the server name are not permitted.  It is not allowed
 252         to request all users on some server.  The WHOIS requests MUST
 253         be based on explicit nickname request.
 254
 255         The WHOIS request MUST be always sent to the router by server
 256         so that all users are searched.  However, the server still MUST
 257         search its locally connected clients.  The router MUST send
 258         this command to the server which owns the requested client, if
 259         the router is unable to provide all mandatory information about
 260         the client.  That server MUST reply to the command.  Server MUST
 261         NOT send whois replies to the client until it has received the
 262         reply from its router.
 263
 264         The <Requested Attributes> is defined in [ATTRS] and can be used
 265         to request various information about the client.  See Appendix A
 266         for definition of using these attributes in SILC.
 267
 268         Reply messages to the command:
 269
 270         Max Arguments:  11
 271             Arguments:  (1) <Status Payload>       (2) <Client ID>
 272                         (3) <nickname>[@<server>]  (4) <username@host>
 273                         (5) <real name>            (6) [<Channel Payload
 274                                                          list>]
 275                         (7) [<user mode>]          (8) [<idle time>]
 276                         (9) [<fingerprint>]        (10) <channel user
 277                                                          mode list>
 278                         (11) [<Attributes>]
 279
 280
 281         This command may reply with several command reply messages to
 282         form a list of results.  In this case the status payload will
 283         include STATUS_LIST_START status in the first reply and
 284         STATUS_LIST_END in the last reply to indicate the end of the
 285         list.  If there are only one reply the status is set to normal
 286         STATUS_OK.
 287
 288         The command replies include the Client ID of the nickname,
 289         nickname and server name, user name and host name and user's real
 290         name.  Client SHOULD process these replies only after the last
 291         reply has been received with the STATUS_LIST_END status.  If the
 292         <count> option were defined in the query there will be only
 293         <count> many replies from the server.
 294
 295         The server returns the list of channels if the client has
 296         joined channels.  In this case the list is list of Channel
 297         Payloads.  The Mode Mask in the Channel Payload is the channel's
 298         mode.  The list is encoded by adding the Channel Payloads one
 299         after the other.  Private and secret channels MUST NOT be sent,
 300         except if the sender of this command is on those channels, or
 301         the sender is server.  The <channel user mode list> MUST also
 302         be sent if client is joined channels.  This list includes 32 bit
 303         MSB first order values one after the other and each indicate
 304         the user's mode on a channel.  The order of these values MUST
 305         be same as the channel order in the <Channel Payload list>.
 306
 307         The server also returns client's user mode, idle time, and the
 308         fingerprint of the client's public key.  The <fingerprint> is the
 309         binary hash digest of the public key.  The fingerprint MUST NOT
 310         be sent if the server has not verified the proof of posession of
 311         the corresponding private key.  Server can do this during the
 312         SILC Key Exchange protocol.  The <fingerprint> is SHA1 digest.
 313
 314         The <Attributes> is the reply to the <Requested Attributes>.
 315         See the Appendix A for more information.
 316
 317         Status messages:
 318
 319             SILC_STATUS_OK
 320             SILC_STATUS_LIST_START
 321             SILC_STATUS_LIST_END
 322             SILC_STATUS_ERR_NO_SUCH_NICK
 323             SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
 324             SILC_STATUS_ERR_WILDCARDS
 325             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 326             SILC_STATUS_ERR_TOO_MANY_PARAMS
 327
 328
 329    2    SILC_COMMAND_WHOWAS
 330
 331         Max Arguments:  2
 332             Arguments:  (1) <nickname>[@<server>]  (2) [<count>]
 333
 334         Whowas.  This command is used to query history information about
 335         specific user.  The user may be requested by their nickname and
 336         server name.  The query may find multiple matching users as there
 337         are no unique nicknames in the SILC.  The <count> option may be
 338         given to narrow down the number of accepted results.  If this
 339         is not defined there are no limit of accepted results.  The query
 340         may also be narrowed down by defining the server name of the
 341         nickname.  The <count> is 32 bit MSB first order integer.
 342
 343         To prevent miss-use of this command wildcards in the nickname
 344         or in the server name are not permitted.  The WHOWAS requests MUST
 345         be based on specific nickname request.
 346
 347         The WHOWAS request MUST be always sent to the router by server
 348         so that all users are searched.  However, the server still must
 349         search its locally connected clients.
 350
 351         Reply messages to the command:
 352
 353         Max Arguments:  5
 354             Arguments:  (1) <Status Payload>        (2) <Client ID>
 355                         (3) <nickname>[@<server>]   (4) <username@host>
 356                         (5) [<real name>]
 357
 358         This command may reply with several command reply messages to form
 359         a list of results.  In this case the status payload will include
 360         STATUS_LIST_START status in the first reply and STATUS_LIST_END in
 361         the last reply to indicate the end of the list.  If there are only
 362         one reply the status is set to normal STATUS_OK.
 363
 364         The command replies with nickname and user name and host name.
 365         Every server MUST keep history for some period of time of its
 366         locally connected clients.
 367
 368         Status messages:
 369
 370             SILC_STATUS_OK
 371             SILC_STATUS_LIST_START
 372             SILC_STATUS_LIST_END
 373             SILC_STATUS_ERR_NO_SUCH_NICK
 374             SILC_STATUS_ERR_WILDCARDS
 375             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 376             SILC_STATUS_ERR_TOO_MANY_PARAMS
 377
 378
 379    3    SILC_COMMAND_IDENTIFY
 380
 381         Max Arguments:  256
 382             Arguments:  (1) [<nickname>[@<server>]]  (2) [<server name>]
 383                         (3) [<channel name>]         (4) [<count>]
 384                         (5) [<ID Payload>]           (n) [...]
 385
 386         Identify command is used to query information about an entity by
 387         the entity's name or ID.  This command can be used to query
 388         information about clients, server and channels.
 389
 390         The query may find multiple matching entities.  The <count> option
 391         may be given to narrow down the number of accepted results.  If
 392         this is not defined there are no limit of accepted results.  The
 393         <count> is 32 bit MSB first order integer.
 394
 395         It is also possible to search the entity by its ID.  If the
 396         <ID Payload> is provided server must use it as the search value
 397         instead of the entity's name.  One of the arguments must be given.
 398         It is also possible to define multiple ID Payloads to search
 399         multiple entities sending only one IDENTIFY command.  In this case
 400         the ID Payloads are appended as normal arguments.  The type of the
 401         entity is defined by the type of the ID Payload.
 402
 403         To prevent miss-use of this command wildcards in the names are
 404         not permitted.  It is not allowed to request for example all users
 405         on server.
 406
 407         Implementations may not want to give interface access to this
 408         command as it is hardly a command that would be used by an end
 409         user.  However, it must be implemented as it is used with private
 410         message sending.
 411
 412         The IDENTIFY command MUST be always sent to the router by server
 413         so that all users are searched.  However, server MUST still search
 414         its locally connected clients.
 415
 416         Reply messages to the command:
 417
 418         Max Arguments:  4
 419             Arguments:  (1) <Status Payload>   (2) <ID Payload>
 420                         (3) [<entity's name>]  (4) [<info>]
 421
 422         This command may reply with several command reply messages to form
 423         a list of results.  In this case the status payload will include
 424         STATUS_LIST_START status in the first reply and STATUS_LIST_END in
 425         the last reply to indicate the end of the list.  If there are only
 426         one reply the status is set to normal STATUS_OK.
 427
 428         When querying clients the <entity's name> must include the client's
 429         nickname in the following format: nickname[@server].  The
 430         <info> must include the client's username and host in the following
 431         format: username@host.
 432
 433         When querying servers the <entity's name> must include the server's
 434         full name.  The <info> may be omitted.
 435
 436         When querying channels the <entity's name> must include the
 437         channel's name.  The <info> may be omitted.
 438
 439         If the <count> option were defined in the query there will be only
 440         <count> many replies from the server.
 441
 442         Status messages:
 443
 444             SILC_STATUS_OK
 445             SILC_STATUS_LIST_START
 446             SILC_STATUS_LIST_END
 447             SILC_STATUS_ERR_NO_SUCH_NICK
 448             SILC_STATUS_ERR_NO_SUCH_SERVER
 449             SILC_STATUS_ERR_NO_SUCH_CHANNEL
 450             SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
 451             SILC_STATUS_ERR_NO_SUCH_SERVER_ID
 452             SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
 453             SILC_STATUS_ERR_WILDCARDS
 454             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 455             SILC_STATUS_ERR_TOO_MANY_PARAMS
 456
 457
 458    4    SILC_COMMAND_NICK
 459
 460         Max Arguments:  1
 461             Arguments:  (1) <nickname>
 462
 463         Set/change nickname.  This command is used to set nickname for
 464         user.  Nickname MUST NOT include any spaces (` '), non-printable
 465         characters, commas (`,') and any wildcard characters.  Note that
 466         nicknames in SILC are case-sensitive which must be taken into
 467         account when searching clients by nickname.
 468
 469         When nickname is changed new Client ID is generated.  Server MUST
 470         distribute SILC_NOTIFY_TYPE_NICK_CHANGE to local clients on the
 471         channels (if any) the client is joined on.  Then it MUST send
 472         SILC_PACKET_REPLACE_ID to its primary route to replace the old
 473         Client ID with the new one.
 474
 475         Reply messages to the command:
 476
 477         Max Arguments:  2
 478             Arguments:  (1) <Status Payload>  (2) <New ID Payload>
 479
 480         This command is replied always with New ID Payload that is
 481         generated by the server every time user changes their nickname.
 482         Client receiving this payload MUST start using the received
 483         Client ID as its current valid Client ID.  The New ID Payload
 484         is described in [SILC2].
 485
 486         Status messages:
 487
 488             SILC_STATUS_OK
 489             SILC_STATUS_ERR_WILDCARDS
 490             SILC_STATUS_ERR_NICKNAME_IN_USE
 491             SILC_STATUS_ERR_BAD_NICKNAME
 492             SILC_STATUS_ERR_NOT_REGISTERED
 493             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 494             SILC_STATUS_ERR_TOO_MANY_PARAMS
 495
 496
 497    5    SILC_COMMAND_LIST
 498
 499         Max Arguments:  1
 500             Arguments:  (1) [<Channel ID>]
 501
 502         The list command is used to list channels and their topics on the
 503         current server.  If the <Channel ID> parameter is used, only the
 504         status of that channel is displayed.  Secret channels are not
 505         listed at all.  Private channels are listed with status indicating
 506         that the channel is private.  Router MAY reply with all channels
 507         it knows about.
 508
 509         Reply messages to the command:
 510
 511         Max Arguments:  5
 512             Arguments:  (1) <Status Payload>  (2) <Channel ID>
 513                         (3) <channel>         (4) [<topic>]
 514                         (5) [<user count>]
 515
 516         This command may reply with several command reply messages to form
 517         a list of results.  In this case the status payload will include
 518         STATUS_LIST_START status in the first reply and STATUS_LIST_END in
 519         the last reply to indicate the end of the list.  If there are only
 520         one reply the status is set to normal STATUS_OK.
 521
 522         This command replies with Channel ID, name and the topic of the
 523         channel.  If the channel is private channel the <topic> SHOULD
 524         include the "*private*" string.
 525
 526         Status messages:
 527
 528             SILC_STATUS_OK
 529             SILC_STATUS_LIST_START
 530             SILC_STATUS_LIST_END
 531             SILC_STATUS_ERR_WILDCARDS
 532             SILC_STATUS_ERR_NOT_REGISTERED
 533             SILC_STATUS_ERR_TOO_MANY_PARAMS
 534             SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
 535             SILC_STATUS_ERR_NO_CHANNEL_ID
 536             SILC_STATUS_ERR_NO_SUCH_SERVER
 537
 538
 539    6    SILC_COMMAND_TOPIC
 540
 541         Max Arguments:  2
 542             Arguments:  (1) <Channel ID>  (2) [<topic>]
 543
 544         This command is used to change or view the topic of a channel.
 545         The topic for channel <Channel ID> is returned if there is no
 546         <topic> given.  If the <topic> parameter is present, the topic
 547         for that channel will be changed, if the channel modes permit
 548         this action.
 549
 550         After setting the topic the server MUST send the notify type
 551         SILC_NOTIFY_TYPE_TOPIC_SET to its primary router and then to
 552         the channel which topic was changed.
 553
 554         Reply messages to the command:
 555
 556         Max Arguments:  2
 557             Arguments:  (1) <Status Payload>  (2) <Channel ID>
 558                         (3) [<topic>]
 559
 560         The command may reply with the topic of the channel if it is
 561         set.
 562
 563         Status messages:
 564
 565             SILC_STATUS_OK
 566             SILC_STATUS_ERR_NOT_ON_CHANNEL
 567             SILC_STATUS_ERR_WILDCARDS
 568             SILC_STATUS_ERR_NOT_REGISTERED
 569             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 570             SILC_STATUS_ERR_NO_SUCH_CHANNEL
 571             SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
 572             SILC_STATUS_ERR_NO_CHANNEL_ID
 573             SILC_STATUS_ERR_BAD_CHANNEL_ID
 574             SILC_STATUS_ERR_TOO_MANY_PARAMS
 575             SILC_STATUS_ERR_NO_CHANNEL_PRIV
 576
 577
 578    7    SILC_COMMAND_INVITE
 579
 580         Max Arguments:  4
 581             Arguments:  (1) <Channel ID>       (2) [<Client ID>]
 582                         (3) [<adding client>]  (4) [<removing client>]
 583
 584         This command is used to invite other clients to join to the
 585         channel.  The <Client ID> argument is the target client's ID that
 586         is being invited.  The <Channel ID> is the Channel ID of the
 587         requested channel.  The sender of this command MUST be on the
 588         channel.  The server MUST also send the notify type
 589         SILC_NOTIFY_TYPE_INVITE to its primary router and then to the
 590         client indicated by the <Client ID>.
 591
 592         The <adding client> and <removing client> can be used to add to
 593         and remove from the invite list.  The format of the <adding client>
 594         and <removing client> is as follows:
 595
 596             [<nickname>[@<server>]!][<username>]@[<hostname>]
 597
 598         When adding to or removing from the invite list the server MUST
 599         send the notify type SILC_NOTIFY_TYPE_INVITE to its primary router
 600         and MUST NOT send it to the client which was added to the list.
 601         The client which executes this command MUST have at least channel
 602         operator privileges to be able to add to or remove from the invite
 603         list.  The wildcards MAY be used with this command.  If adding or
 604         removing more than one client then the lists are an comma (`,')
 605         separated.
 606
 607         Note that the <Client ID> provided MUST be resolved into correct
 608         nickname and host name and add to the invite list before sending
 609         the notify packet.
 610
 611         When this command is given with only <Channel ID> argument then
 612         the command merely returns the invite list of the channel.   This
 613         command MUST fail if the requested channel does not exist, the
 614         requested <Client ID> is already on the channel or if the channel
 615         is invite only channel and the caller of this command does not
 616         have at least channel operator privileges.
 617
 618         Reply messages to the command:
 619
 620         Max Arguments:  3
 621             Arguments:  (1) <Status Payload>  (2) <Channel ID>
 622                         (3) [<invite list>]
 623
 624         This command replies with the invite list of the channel if it
 625         exists.
 626
 627         Status messages:
 628
 629             SILC_STATUS_OK
 630             SILC_STATUS_ERR_NOT_REGISTERED
 631             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 632             SILC_STATUS_ERR_TOO_MANY_PARAMS
 633             SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
 634             SILC_STATUS_ERR_NO_CLIENT_ID
 635             SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
 636             SILC_STATUS_ERR_NO_CHANNEL_ID
 637             SILC_STATUS_ERR_NOT_ON_CHANNEL
 638             SILC_STATUS_ERR_USER_ON_CHANNEL
 639             SILC_STATUS_ERR_NO_CHANNEL_PRIV
 640
 641
 642    8    SILC_COMMAND_QUIT
 643
 644         Max Arguments:  1
 645             Arguments:  (1) [<quit message>]
 646
 647         This command is used by client to end SILC session.  The server
 648         must close the connection to a client which sends this command.
 649         if <quit message> is given it will be sent to other clients on
 650         channel if the client is on channel when quitting.
 651
 652         Reply messages to the command:
 653
 654         This command does not reply anything.
 655
 656
 657     9   SILC_COMMAND_KILL
 658
 659         Max Arguments:  2
 660             Arguments:  (1) <Client ID>  (2) [<comment>]
 661
 662         This command is used by SILC operators to remove a client from
 663         SILC network.  The removing has temporary effects and client may
 664         reconnect to SILC network.  The <Client ID> is the client to be
 665         removed from SILC.  The <comment> argument may be provided to
 666         give to the removed client some information why it was removed
 667         from the network.
 668
 669         When killing a client the router MUST first send notify type
 670         SILC_NOTIFY_TYPE_KILLED to all channels the client has joined.
 671         The packet MUST NOT be sent to the killed client on the channels.
 672         Then, the router MUST send the same notify type to its primary
 673         router.  Finally, the router MUST send the same notify type
 674         directly to the client which was killed.
 675
 676         Reply messages to the command:
 677
 678         Max Arguments:  1
 679             Arguments:  (1) <Status Payload>
 680
 681         This command replies only with Status Payload.
 682
 683         Status messages:
 684
 685             SILC_STATUS_OK
 686             SILC_STATUS_ERR_WILDCARDS
 687             SILC_STATUS_ERR_NOT_REGISTERED
 688             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 689             SILC_STATUS_ERR_TOO_MANY_PARAMS
 690             SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
 691             SILC_STATUS_ERR_NO_CLIENT_ID
 692             SILC_STATUS_ERR_NO_ROUTER_PRIV
 693
 694
 695    10   SILC_COMMAND_INFO
 696
 697         Max Arguments:  2
 698             Arguments:  (1) [<server>]  (2) [<Server ID>]
 699
 700         This command is used to fetch various information about a server.
 701         If <server> argument is specified the command MUST be sent to
 702         the requested server.
 703
 704         If the <Server ID> is specified the server information if fetched
 705         by the provided Server ID.  One of the arguments must always be
 706         present.
 707
 708         Reply messages to the command:
 709
 710         Max Arguments:  4
 711             Arguments:  (1) <Status Payload>  (2) <Server ID>
 712                         (3) <server name>     (4) <string>
 713
 714         This command replies with the Server ID of the server and a
 715         string which tells the information about the server.
 716
 717         Status messages:
 718
 719             SILC_STATUS_OK
 720             SILC_STATUS_ERR_WILDCARDS
 721             SILC_STATUS_ERR_NOT_REGISTERED
 722             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 723             SILC_STATUS_ERR_TOO_MANY_PARAMS
 724             SILC_STATUS_ERR_NO_SUCH_SERVER
 725             SILC_STATUS_ERR_NO_SUCH_SERVER_ID
 726             SILC_STATUS_ERR_NO_SERVER_ID
 727
 728
 729    11   SILC_COMMAND_STATS
 730
 731         Max Arguments:  1
 732             Arguments:  (1) <Server ID>
 733
 734         This command is used to fetch various statistical information
 735         from the server indicated by <Server ID>, which is the ID of
 736         server where sender is connected to.  Server receiving this
 737         command MAY also send this further to its router for fetching
 738         other cell and network wide statistics to accompany the reply.
 739
 740         Reply messages to the command:
 741
 742         Max Arguments:  3
 743             Arguments:  (1) <Status Payload>          (2) <Server ID>
 744                         (3) [<statistics structure>]
 745
 746         This command replies with the Server ID of the server and
 747         optional statistics structure which includes 32 bit MSB first
 748         ordered integer values to represent various statistical
 749         information.  The structure is as follows:
 750
 751           starttime      - time when server was started
 752           uptime         - uptime of the server
 753           my clients     - number of locally connected clients
 754           my channels    - number of locally created channels
 755           my server ops  - number of local server operators
 756           my router ops  - number of local router operators
 757           cell clients   - number of clients in local cell
 758           cell channels  - number of channels in local cell
 759           cell servers   - number of servers in local cell
 760           clients        - number of client in SILC network
 761           channels       - number of channels in SILC network
 762           servers        - number of servers in SILC network
 763           routers        - number of routers in SILC network
 764           server ops     - number of server operators in SILC network
 765           router ops     - number of router operators in SILC network
 766
 767         If some value is unknown it is set to zero (0) value.  The
 768         "starttime" is the start time of the server, and is seconds
 769         since Epoch (POSIX.1).  The "uptime" is time difference of
 770         current time and "starttime" in the server, and is seconds
 771         in value.
 772
 773         Status messages:
 774
 775             SILC_STATUS_OK
 776             SILC_STATUS_ERR_NOT_REGISTERED
 777             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 778             SILC_STATUS_ERR_TOO_MANY_PARAMS
 779             SILC_STATUS_ERR_NO_SUCH_SERVER_ID
 780             SILC_STATUS_ERR_NO_SUCH_SERVER
 781             SILC_STATUS_ERR_NO_SERVER_ID
 782
 783
 784    12   SILC_COMMAND_PING
 785
 786         Max Arguments:  1
 787             Arguments:  (1) <Server ID>
 788
 789         This command is used by client and server to test the communication
 790         channel to its server if one suspects that the communication is not
 791         working correctly.  The <Server ID> is the ID of the server the
 792         sender is connected to.
 793
 794         Reply messages to the command:
 795
 796         Max Arguments:  1
 797             Arguments:  (1) <Status Payload>
 798
 799         This command replies only with Status Payload.  Server returns
 800         SILC_STATUS_OK in Status Payload if pinging was successful.
 801
 802
 803
 804         Status messages:
 805
 806             SILC_STATUS_OK
 807             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 808             SILC_STATUS_ERR_TOO_MANY_PARAMS
 809             SILC_STATUS_ERR_NO_SERVER_ID
 810             SILC_STATUS_ERR_NO_SUCH_SERVER
 811             SILC_STATUS_ERR_NOT_REGISTERED
 812
 813
 814    13   SILC_COMMAND_OPER
 815
 816         Max Arguments:  2
 817             Arguments:  (1) <username>  (2) <authentication payload>
 818
 819         This command is used by normal client to obtain server operator
 820         privileges on some server or router.  Note that router operator
 821         has router privileges that supersedes the server operator
 822         privileges and this does not obtain those privileges.  Client
 823         MUST use SILCOPER command to obtain router level privileges.
 824
 825         The <username> is the username set in the server configurations
 826         as operator.  The <authentication payload> is the data that the
 827         client is authenticated against.  It may be passphrase prompted
 828         for user on client's screen or it may be public key or certificate
 829         authentication data (data signed with private key).  The public
 830         key that server will use to verify the signature found in the
 831         payload should be verified.  It is recommended that the public
 832         key is saved locally in the server and server would not use
 833         any public keys received during the SKE.
 834
 835         After changing the mode the server MUST send the notify type
 836         SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
 837
 838         Reply messages to the command:
 839
 840         Max Arguments:  1
 841             Arguments:  (1) <Status Payload>
 842
 843         This command replies only with Status Payload.
 844
 845         Status messages:
 846
 847             SILC_STATUS_OK
 848             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 849             SILC_STATUS_ERR_TOO_MANY_PARAMS
 850             SILC_STATUS_ERR_NOT_REGISTERED
 851             SILC_STATUS_ERR_AUTH_FAILED
 852
 853
 854    14   SILC_COMMAND_JOIN
 855
 856         Max Arguments:  6
 857             Arguments:  (1) <channel>       (2) <Client ID>
 858                         (3) [<passphrase>]  (4) [<cipher>]
 859                         (5) [<hmac>]        (6) [<founder auth>]
 860
 861         Join to channel/create new channel.  This command is used to
 862         join to a channel.  If the channel does not exist the channel is
 863         created.  If server is normal server this command MUST be sent
 864         to router which will create the channel.  The channel MAY be
 865         protected with passphrase.  If this is the case the passphrase
 866         MUST be sent along the join command.
 867
 868         The name of the <channel> MUST NOT include any spaces (` '),
 869         non-printable characters, commas (`,') or any wildcard characters.
 870
 871         The second argument <Client ID> is the Client ID of the client
 872         which is joining to the client.  When client sends this command
 873         to the server the <Client ID> MUST be the client's own ID.
 874
 875         Cipher to be used to secure the traffic on the channel MAY be
 876         requested by sending the name of the requested <cipher>.  This
 877         is used only if the channel does not exist and is created.  If
 878         the channel already exists the cipher set previously for the
 879         channel will be used to secure the traffic.  The computed MACs
 880         of the channel message are produced by the default HMAC or by
 881         the <hmac> provided for the command.
 882
 883         The <founder auth> is Authentication Payload providing the
 884         authentication for gaining founder privileges on the channel
 885         when joining the channel.  The client may provide this if it
 886         knows that it is the founder of the channel and that the
 887         SILC_CMODE_FOUNDER_AUTH mode is set on the channel.  The server
 888         MUST verify whether the client is able to gain the founder
 889         privileges the same way as the client had given the
 890         SILC_COMMAND_CUMODE command to gain founder privileges.  The
 891         client is still able to join the channel even if the founder
 892         privileges could not be gained.
 893
 894         The server MUST check whether the user is allowed to join to
 895         the requested channel.  Various modes set to the channel affect
 896         the ability of the user to join the channel.  These conditions
 897         are:
 898
 899             o  The user MUST be invited to the channel if the channel
 900                is invite-only channel.
 901
 902             o  The Client ID/nickname/username/host name MUST NOT match
 903                any active bans.
 904
 905             o  The correct passphrase MUST be provided if passphrase
 906                is set to the channel.
 907
 908             o  The user count limit, if set, MUST NOT be reached.
 909
 910         If the client provided correct <founder auth> payload it can
 911         override these conditions, except the condition for the passphrase.
 912         The correct passphrase MUST be provided even if <founder auth>
 913         payload is provided.
 914
 915         Reply messages to the command:
 916
 917         Max Arguments:  14
 918             Arguments:  (1) <Status Payload>        (2) <channel>
 919                         (3) <Channel ID>            (4) <Client ID>
 920                         (5) <channel mode mask>     (6) <created>
 921                         (7) [<Channel Key Payload>] (8) [<ban list>]
 922                         (9) [<invite list>]         (10) [<topic>]
 923                         (11) [<hmac>]               (12) <list count>
 924                         (13) <Client ID list>       (14) <client mode list>
 925
 926         This command replies with the channel name requested by the
 927         client, channel ID of the channel and topic of the channel
 928         if it exists.  The <Client ID> is the Client ID which was joined
 929         to the channel.  It also replies with the channel mode mask
 930         which tells all the modes set on the channel.  If the
 931         channel is created the mode mask is zero (0).  If ban mask
 932         and/or invite list is set they are sent as well.
 933
 934         The <list count>, <Client ID list> and <client mode list> are
 935         the clients currently on the channel and their modes on the
 936         channel.  The <Client ID list> is formed by adding the ID Payloads
 937         one after the other.  The <client mode list> is formed by adding
 938         32 bit MSB first order values one after the other.
 939
 940         Client receives the channel key in the reply message as well
 941         inside <Channel Key Payload>.
 942
 943         Status messages:
 944
 945             SILC_STATUS_OK
 946             SILC_STATUS_ERR_WILDCARDS
 947             SILC_STATUS_ERR_NOT_REGISTERED
 948             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 949             SILC_STATUS_ERR_TOO_MANY_PARAMS
 950             SILC_STATUS_ERR_BAD_PASSWORD
 951             SILC_STATUS_ERR_CHANNEL_IS_FULL
 952             SILC_STATUS_ERR_NOT_INVITED
 953             SILC_STATUS_ERR_BANNED_FROM_CHANNEL
 954             SILC_STATUS_ERR_BAD_CHANNEL
 955             SILC_STATUS_ERR_USER_ON_CHANNEL
 956
 957
 958    15   SILC_COMMAND_MOTD
 959
 960         Max Arguments:  1
 961             Arguments:  (1) <server>
 962
 963         This command is used to query the Message of the Day of the server.
 964
 965         Reply messages to the command:
 966
 967         Max Arguments:  3
 968             Arguments:  (1) <Status Payload>  (2) <Server ID>
 969                         (3) [<motd>]
 970
 971         This command replies with the motd message if it exists.
 972
 973         Status messages:
 974
 975             SILC_STATUS_OK
 976             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
 977             SILC_STATUS_ERR_TOO_MANY_PARAMS
 978             SILC_STATUS_ERR_NOT_REGISTERED
 979             SILC_STATUS_ERR_NO_SUCH_SERVER
 980
 981
 982    16   SILC_COMMAND_UMODE
 983
 984         Max Arguments:  2
 985             Arguments:  (1) <Client ID>  (2) [<client mode mask>]
 986
 987         This command is used by client to set/unset modes for itself.
 988         However, there are some modes that the client MUST NOT set itself,
 989         but they will be set by server.  However, client MAY unset any
 990         mode.  Modes may be masked together ORing them thus having
 991         several modes set.  Client MUST keep its client mode mask
 992         locally so that the mode setting/unsetting would work without
 993         problems.  Client may change only its own modes.
 994
 995         After changing the mode server MUST send the notify type
 996         SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
 997
 998         The following client modes are defined:
 999
1000            0x00000000    SILC_UMODE_NONE
1001
1002               No specific mode for client.  This is the initial
1003               setting when new client is created.  The client is
1004               normal client and is present in the network.
1005
1006
1007            0x00000001    SILC_UMODE_SERVER_OPERATOR
1008
1009               Marks the user as server operator.  Client MUST NOT
1010               set this mode itself.  Server sets this mode to the
1011               client when client attains the server operator
1012               privileges by SILC_COMMAND_OPER command.  Client
1013               MAY unset the mode itself.
1014
1015
1016            0x00000002    SILC_UMODE_ROUTER_OPERATOR
1017
1018               Marks the user as router (SILC) operator.  Client
1019               MUST NOT set this mode itself.  Router sets this mode
1020               to the client when client attains the router operator
1021               privileges by SILC_COMMAND_SILCOPER command.  Client
1022               MAY unset the mode itself.
1023
1024
1025            0x00000004    SILC_UMODE_GONE
1026
1027               Marks that the user is not currently present in the
1028               SILC Network.  Client MAY set and unset this mode.
1029
1030
1031            0x00000008    SILC_UMODE_INDISPOSED
1032
1033               Marks that the user is currently indisposed and may
1034               not be able to receive any messages, and that user may
1035               not be present in the network.  Client MAY set and
1036               unset this mode.
1037
1038
1039            0x00000010    SILC_UMODE_BUSY
1040
1041               Marks that the user is currently busy and may not
1042               want to receive any messages, and that user may not
1043               be present in the network.  Client MAY set and unset
1044               this mode.
1045
1046
1047            0x00000020    SILC_UMODE_PAGE
1048
1049               User is not currently present or is unable to receive
1050               messages, and prefers to be paged in some mechanism
1051               if the user needs to be reached.  Client MAY set and
1052               unset this mode.
1053
1054
1055            0x00000040    SILC_UMODE_HYPER
1056
1057               Marks that the user is hyper active and is eager to
1058               receive and send messages.   Client MAY set and unset
1059               this mode.
1060
1061
1062            0x00000080    SILC_UMODE_ROBOT
1063
1064               Marks that the client is actually a robot program.
1065               Client MAY set and unset this mode.
1066
1067
1068            0x00000100    SILC_UMODE_ANONYMOUS
1069
1070               Marks that the client is anonymous client.  Server
1071               that specificly is designed for anonymous services
1072               can set and unset this mode.  Client MUST NOT set or
1073               unset this mode itself.  A client with this mode set
1074               would have the username and the hostname information
1075               scrambled by the server which set this mode.
1076
1077
1078            0x00000200    SILC_UMODE_BLOCK_PRIVMSG
1079
1080               Marks that the client wishes to block private
1081               messages sent to the client, unless the Private
1082               Message Key flag is set in the SILC packet header.
1083               If this mode is set server MUST NOT deliver private
1084               messages to the client without the Private Message
1085               Key flag being set.
1086
1087               A separate service could provide additional filtering
1088               features for accepting private messages from certain
1089               sender.  However, this document does not specify such
1090               service.
1091
1092               The client MAY set and unset this mode.
1093
1094
1095            0x00000400    SILC_UMODE_DETACHED
1096
1097               Marks that the client is detached from the SILC network.
1098               This means that the actual network connection to the
1099               client is lost but the client entry is still valid.  The
1100               detached client can be resumed at a later time.  This
1101               mode MUST NOT be set by client.  It can only be set when
1102               client has issued command SILC_COMMAND_DETACH.  The server
1103               sets this mode.  This mode cannot be unset with this
1104               command.  It is unset when the client is resuming back to
1105               the network and SILC_PACKET_RESUME_CLIENT packet is
1106               received.
1107
1108               This flag MUST NOT be used to determine whether a packet
1109               can be sent to the client or not.  Only the server that
1110               had the original client connection can make the decision
1111               by knowing that the network connection is not active.
1112               In this case the default case is to discard the packet.
1113
1114         If the <client mode mask> was not provided this command merely
1115         returns the mode mask to the client.
1116
1117
1118         Reply messages to the command:
1119
1120         Max Arguments:  2
1121             Arguments:  (1) <Status Payload>  (2) <client mode mask>
1122
1123         This command replies with the changed client mode mask that
1124         the client MUST to keep locally.
1125
1126
1127         Status messages:
1128
1129             SILC_STATUS_OK
1130             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
1131             SILC_STATUS_ERR_TOO_MANY_PARAMS
1132             SILC_STATUS_ERR_NOT_REGISTERED
1133             SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
1134             SILC_STATUS_ERR_BAD_CLIENT_ID
1135             SILC_STATUS_ERR_NOT_YOU
1136             SILC_STATUS_ERR_PERM_DENIED
1137             SILC_STATUS_ERR_UNKNOWN_MODE
1138             SILC_STATUS_ERR_NO_CLIENT_ID
1139
1140
1141    17   SILC_COMMAND_CMODE
1142
1143         Max Arguments:  7
1144             Arguments:  (1) <Channel ID>      (2) [<channel mode mask>]
1145                         (3) [<user limit>]    (4) [<passphrase>]
1146                         (5) [<cipher>]        (6) [<hmac>]
1147                         (7) [<auth payload>]
1148
1149         This command is used by client to set or change channel flags on
1150         a channel.  Channel has several modes that set various properties
1151         of a channel.  Modes may be masked together by ORing them thus
1152         having several modes set.  The <Channel ID> is the ID of the
1153         target channel.  The client changing channel mode MUST be on
1154         the same channel and poses sufficient privileges to be able to
1155         change the mode.
1156
1157         When the mode is changed SILC_NOTIFY_TYPE_CMODE_CHANGE notify
1158         type MUST be distributed to the channel.
1159
1160         The following channel modes are defined:
1161
1162            0x00000000    SILC_CMODE_NONE
1163
1164               No specific mode on channel.  This is the default when
1165               channel is created.  This means that channel is just plain
1166               normal channel.
1167
1168
1169            0x00000001    SILC_CMODE_PRIVATE
1170
1171               Channel is private channel.  Private channels are shown
1172               in the channel list listed with SILC_COMMAND_LIST command
1173               with indication that the channel is private.  Also,
1174               client on private channel will no be detected to be on
1175               the channel as the channel is not shown in the client's
1176               currently joined channel list.  Channel founder and
1177               channel operator MAY set/unset this mode.
1178
1179               Typical implementation would use [+|-]p on user interface
1180               to set/unset this mode.
1181
1182
1183            0x00000002    SILC_CMODE_SECRET
1184
1185               Channel is secret channel.  Secret channels are not shown
1186               in the list listed with SILC_COMMAND_LIST command.  Secret
1187               channels can be considered to be invisible channels.
1188               Channel founder and channel operator MAY set/unset this
1189               mode.
1190
1191               Typical implementation would use [+|-]s on user interface
1192               to set/unset this mode.
1193
1194
1195            0x00000004    SILC_CMODE_PRIVKEY
1196
1197               Channel uses private channel key to protect the traffic
1198               on the channel.  When this mode is set the client will be
1199               responsible to set the key it wants to use to encrypt and
1200               decrypt the traffic on channel.  Server generated channel
1201               keys are not used at all.  This mode provides additional
1202               security as clients on channel may agree to use private
1203               channel key that even servers do not know.  Naturally,
1204               this requires that every client on the channel knows
1205               the key before hand (it is considered to be pre-shared-
1206               key).  The key material is RECOMMENDED to be processed
1207               as stated in the [SILC3] in the section Processing the
1208               Key Material.
1209
1210               As it is local setting it is possible to have several
1211               private channel keys on one channel.  In this case several
1212               clients can talk on same channel but only those clients
1213               that share the key with the message sender will be able
1214               to hear the talking.  Client SHOULD NOT display those
1215               message for the end user that it is not able to decrypt
1216               when this mode is set.
1217
1218               Only channel founder MAY set/unset this mode.  If this
1219               mode is unset the server will distribute new channel
1220               key to all clients on the channel which will be used
1221               thereafter.
1222
1223               Typical implementation would use [+|-]k on user interface
1224               to set/unset this mode.
1225
1226
1227            0x00000008    SILC_CMODE_INVITE
1228
1229               Channel is invite only channel.  Client may join to this
1230               channel only if it is invited to the channel.  Channel
1231               founder and channel operator MAY set/unset this mode.
1232
1233               Typical implementation would use [+|-]i on user interface
1234               to set/unset this mode.
1235
1236
1237            0x00000010    SILC_CMODE_TOPIC
1238
1239               The topic of the channel may only be set by client that
1240               is channel founder or channel operator.  Normal clients
1241               on channel will not be able to set topic when this mode
1242               is set.  Channel founder and channel operator MAY set/
1243               unset this mode.
1244
1245               Typical implementation would use [+|-]t on user interface
1246               to set/unset this mode.
1247
1248
1249            0x00000020    SILC_CMODE_ULIMIT
1250
1251               User limit has been set to the channel.  New clients
1252               may not join to the channel when the limit set is
1253               reached.  Channel founder and channel operator MAY set/
1254               unset the limit.  The <user limit> argument is the
1255               number of limited users.
1256
1257               Typical implementation would use [+|-]l on user interface
1258               to set/unset this mode.
1259
1260
1261            0x00000040    SILC_CMODE_PASSPHRASE
1262
1263               Passphrase has been set to the channel.  Client may
1264               join to the channel only if it is able to provide the
1265               correct passphrase.  Setting passphrases to channel
1266               is entirely safe as all commands are protected in the
1267               SILC network.  Only channel founder MAY set/unset
1268               the passphrase.  The <passphrase> argument is the
1269               set passphrase.
1270
1271               Typical implementation would use [+|-]a on user interface
1272               to set/unset this mode.
1273
1274
1275            0x00000080    SILC_CMODE_CIPHER
1276
1277               Sets specific cipher to be used to protect channel
1278               traffic.  The <cipher> argument is the requested cipher.
1279               When set or unset the server must re-generate new
1280               channel key.  Only channel founder MAY set the cipher of
1281               the channel.  When unset the new key is generated using
1282               default cipher for the channel.
1283
1284               Typical implementation would use [+|-]c on user interface
1285               to set/unset this mode.
1286
1287
1288            0x00000100    SILC_CMODE_HMAC
1289
1290               Sets specific hmac to be used to compute the MACs of the
1291               channel message.  The <hmac> argument is the requested hmac.
1292               Only channel founder may set the hmac of the channel.
1293
1294               Typical implementation would use [+|-]h on user interface
1295               to set/unset this mode.
1296
1297
1298            0x00000200    SILC_CMODE_FOUNDER_AUTH
1299
1300               Channel founder may set this mode to be able to regain
1301               channel founder rights even if the client leaves the
1302               channel.  The <auth payload> is the Authentication Payload
1303               consisting of the authentication method and authentication
1304               data to be used in the authentication.  The server MUST
1305               NOT accept NONE authentication method.  Also, if the
1306               method is public key authentication the server MUST NOT
1307               save the authentication data from the payload as the
1308               data is different on all authentications.  In this case the
1309               server only saves the authentication method.  However,
1310               server MUST verify the sent authentication payload and
1311               set the mode only if the verification was successful.
1312
1313               Note that this mode is effective only in the current server.
1314               The client MUST connect to the same server later to be able
1315               to regain the channel founder rights.  The server MUST save
1316               the public key of the channel founder and use that to identify
1317               the client which is claiming the channel founder rights.
1318               The rights may be claimed by the SILC_CUMODE_FOUNDER
1319               channel user mode using SILC_COMMAND_CUMODE command.  The
1320               set authentication data remains valid as long as the channel
1321               exists or until the founder unsets this mode.
1322
1323               Typical implementation would use [+|-]f on user interface
1324               to set/unset this mode.
1325
1326
1327            0x00000400    SILC_CMODE_SILENCE_USERS
1328
1329               Channel founder may set this mode to silence normal users
1330               on the channel.  Users with operator privileges are not
1331               affected by this mode.  Messages sent by normal users
1332               are dropped by servers when this mode is set.  This mode
1333               can be used to moderate the channel.  Only channel founder
1334               may set/unset this mode.
1335
1336
1337            0x00000800    SILC_CMODE_SILENCE_OPERS
1338
1339               Channel founder may set this mode to silence operators
1340               on the channel.  When used with SILC_CMODE_SILENCE_USERS
1341               mode this can be used to set the channel in state where only
1342               the founder of the channel may send messages to the channel.
1343               Messages sent by operators are dropped by servers when this
1344               mode is set.  Only channel founder may set/unset this mode.
1345
1346
1347         To make the mode system work, client MUST keep the channel mode
1348         mask locally so that the mode setting and unsetting would work
1349         without problems.  The client receives the initial channel mode
1350         mask when it joins to the channel.  When the mode changes on
1351         channel the server MUST distribute the changed channel mode mask
1352         to all clients on the channel by sending the notify type
1353         SILC_NOTIFY_TYPE_CMODE_CHANGE.  The notify type MUST also be sent
1354         to the server's primary router.  If the <channel mode mask> was
1355         not provided this command merely returns the mode mask to the
1356         client.
1357
1358         Reply messages to the command:
1359
1360         Max Arguments:  3
1361             Arguments:  (1) <Status Payload>  (2) <Channel ID>
1362                         (3) <channel mode mask>
1363
1364         This command replies with the changed channel mode mask that
1365         client MUST keep locally.
1366
1367         Status messages:
1368
1369             SILC_STATUS_OK
1370             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
1371             SILC_STATUS_ERR_TOO_MANY_PARAMS
1372             SILC_STATUS_ERR_NOT_REGISTERED
1373             SILC_STATUS_ERR_NOT_ON_CHANNEL
1374             SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
1375             SILC_STATUS_ERR_BAD_CHANNEL_ID
1376             SILC_STATUS_ERR_NO_CHANNEL_ID
1377             SILC_STATUS_ERR_NO_CHANNEL_PRIV
1378             SILC_STATUS_ERR_NO_CHANNEL_FOPRIV
1379             SILC_STATUS_ERR_UNKNOWN_MODE
1380             SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
1381             SILC_STATUS_ERR_AUTH_FAILED
1382
1383
1384    18   SILC_COMMAND_CUMODE
1385
1386         Max Arguments:  4
1387             Arguments:  (1) <Channel ID>    (2) <mode mask>
1388                         (3) <Client ID>     (4) [<auth payload>]
1389
1390         This command is used by client to change channel user modes on
1391         channel.  Users on channel may have some special modes and this
1392         command is used by channel operators to set or change these modes.
1393         The <Channel ID> is the ID of the target channel.  The <mode mask>
1394         is OR'ed mask of modes.  The <Client ID> is the target client.
1395         The client changing channel user modes MUST be on the same channel
1396         as the target client and poses sufficient privileges to be able to
1397         change the mode.
1398
1399         When the mode is changed SILC_NOTIFY_TYPE_CUMODE_CHANGE notify
1400         type is distributed to the channel.
1401
1402         The following channel modes are defined:
1403
1404            0x00000000    SILC_CUMODE_NONE
1405
1406               No specific mode.  This is the normal situation for client.
1407               Also, this is the mode set when removing all modes from
1408               the target client.
1409
1410
1411            0x00000001    SILC_CUMODE_FOUNDER
1412
1413               The client is channel founder of the channel.  Usually this
1414               mode is set only by the server when the channel was created.
1415               However, if the SILC_CMODE_FOUNDER_AUTH channel mode has
1416               been set, the client can claim channel founder privileges
1417               by providing the <auth payload> that the server will use
1418               to authenticate the client.  The public key that server will
1419               use to verify the <auth payload> must the same public key
1420               that was saved when the SILC_CMODE_FOUNDER_AUTH channel
1421               mode was set.  The client MAY remove this mode at any time.
1422
1423
1424            0x00000002    SILC_CUMODE_OPERATOR
1425
1426               Sets channel operator privileges on the channel for a
1427               client on the channel.  Channel founder and channel operator
1428               MAY set/unset this mode.  The client MAY remove this mode
1429               at any time.
1430
1431
1432            0x00000004    SILC_CUMODE_BLOCK_MESSAGES
1433
1434               Marks that the client wishes not to receive any channel
1435               messages sent for the channel.  Client MAY set and unset
1436               this mode to itself.  Client MUST NOT set it to anyone else.
1437               When this mode is set server MUST NOT deliver channel
1438               messages to this client.  Other packets such as channel
1439               key packets are still sent to the client.
1440
1441               A separate service could provide additional filtering
1442               features for accepting channel messages from certain
1443               sender.  However, this document does not specify such
1444               service.
1445
1446
1447         Reply messages to the command:
1448
1449         Max Arguments:  4
1450             Arguments:  (1) <Status Payload>  (2) <channel user mode mask>
1451                         (3) <Channel ID>      (4) <Client ID>
1452
1453         This command replies with the changed channel user mode mask that
1454         client MUST keep locally. The <Channel ID> is the specified
1455         channel.  The <Client ID> is the target client.
1456
1457         Status messages:
1458
1459             SILC_STATUS_OK
1460             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
1461             SILC_STATUS_ERR_TOO_MANY_PARAMS
1462             SILC_STATUS_ERR_NOT_REGISTERED
1463             SILC_STATUS_ERR_NOT_ON_CHANNEL
1464             SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
1465             SILC_STATUS_ERR_BAD_CHANNEL_ID
1466             SILC_STATUS_ERR_NO_CHANNEL_ID
1467             SILC_STATUS_ERR_NO_CHANNEL_PRIV
1468             SILC_STATUS_ERR_NO_CHANNEL_FOPRIV
1469             SILC_STATUS_ERR_UNKNOWN_MODE
1470             SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
1471             SILC_STATUS_ERR_AUTH_FAILED
1472
1473
1474    19   SILC_COMMAND_KICK
1475
1476         Max Arguments:  3
1477             Arguments:  (1) <Channel ID>  (2) <Client ID>
1478                         (3) [<comment>]
1479
1480         This command is used by channel operators to remove a client from
1481         channel.  The <channel> argument is the channel the client to be
1482         removed is on currently.  Note that the "kicker" must be on the same
1483         channel.  If <comment> is provided it will be sent to the removed
1484         client.
1485
1486         After kicking the client the server MUST send the notify type
1487         SILC_NOTIFY_TYPE_KICKED to the channel and to its primary router.
1488         The channel key MUST also be re-generated after kicking, unless
1489         the SILC_CMODE_PRIVKEY mode is set.
1490
1491         Reply messages to the command:
1492
1493         Max Arguments:  1
1494             Arguments:  (1) <Status Payload>
1495
1496         This command replies only with Status Payload.
1497
1498         Status messages:
1499
1500             SILC_STATUS_OK
1501             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
1502             SILC_STATUS_ERR_TOO_MANY_PARAMS
1503             SILC_STATUS_ERR_NOT_REGISTERED
1504             SILC_STATUS_ERR_NO_SUCH_CHANNEL
1505             SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
1506             SILC_STATUS_ERR_NO_CHANNEL_PRIV
1507             SILC_STATUS_ERR_NO_CLIENT_ID
1508
1509
1510    20   SILC_COMMAND_BAN
1511
1512         Max Arguments:  3
1513             Arguments:  (1) <Channel ID>         (2) [<adding client>]
1514                         (3) [<removing client>]
1515
1516         This command is used to manage the ban list of the channel
1517         indicated by the <Channel ID>.  A client that is banned from
1518         channel is no longer able to join the channel.  The client which
1519         is executing this command MUST have at least channel operator
1520         privileges on the channel.
1521
1522         The <adding client> and <removing client> are used to add to and
1523         remove from the ban list.  The format of the <adding client> and
1524         the <removing client> is of following format:
1525
1526             [<nickname>[@<server>]!][<username>]@[<hostname>]
1527
1528         The server MUST send the notify type SILC_NOTIFY_TYPE_BAN to its
1529         primary router after adding to or removing from the ban list.
1530         The wildcards MAY be used with this command.  If adding or removing
1531         from than one clients then the lists are an comma (`,') separated.
1532
1533         If this command is executed without the ban arguments the command
1534         merely replies with the current ban list.
1535
1536
1537         Reply messages to the command:
1538
1539         Max Arguments:  3
1540             Arguments:  (1) <Status Payload>  (2) <Channel ID>
1541                         (3) [<ban list>]
1542
1543         This command replies with the <Channel ID> of the channel and
1544         the current <ban list> of the channel if it exists.
1545
1546         Status messages:
1547
1548             SILC_STATUS_OK
1549             SILC_STATUS_ERR_NOT_REGISTERED
1550             SILC_STATUS_ERR_TOO_MANY_PARAMS
1551             SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
1552             SILC_STATUS_ERR_NO_CHANNEL_ID
1553             SILC_STATUS_ERR_NOT_ON_CHANNEL
1554             SILC_STATUS_ERR_NO_CHANNEL_PRIV
1555
1556
1557    21   <deprecated command>
1558
1559
1560    22   <deprecated command>
1561
1562
1563    23   SILC_COMMAND_SILCOPER
1564
1565         Max Arguments:  2
1566             Arguments:  (1) <username>  (2) <authentication payload>
1567
1568         This command is used by normal client to obtain router operator
1569         privileges (also known as SILC operator) on the router.  Note
1570         that router operator has privileges that supersedes the server
1571         operator privileges.
1572
1573         The <username> is the username set in the server configurations
1574         as operator.  The <authentication payload> is the data that the
1575         client is authenticated against.  It may be passphrase prompted
1576         for user on client's screen or it may be public key or certificate
1577         authentication data (data signed with private key).  The public
1578         key that router will use to verify the signature found in the
1579         payload should be verified.  It is recommended that the public
1580         key is saved locally in the router and router would not use
1581         any public keys received during the SKE.
1582
1583         Difference between router operator and server operator is that
1584         router operator is able to handle cell level properties while
1585         server operator (even on router server) is able to handle only
1586         local properties, such as, local connections and normal server
1587         administration.  The router operator is also able to use the
1588         SILC_COMMAND_KILL command.
1589
1590         After changing the mode server MUST send the notify type
1591         SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
1592
1593         Reply messages to the command:
1594
1595         Max Arguments:  1
1596             Arguments:  (1) <Status Payload>
1597
1598         This command replies only with Status Payload.
1599
1600         Status messages:
1601
1602             SILC_STATUS_OK
1603             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
1604             SILC_STATUS_ERR_TOO_MANY_PARAMS
1605             SILC_STATUS_ERR_NOT_REGISTERED
1606             SILC_STATUS_ERR_AUTH_FAILED
1607
1608
1609    24   SILC_COMMAND_LEAVE
1610
1611         Max Arguments:  1
1612             Arguments:  (1) <Channel ID>
1613
1614         This command is used by client to leave a channel the client is
1615         joined to.
1616
1617         When leaving channel the server MUST send the notify type
1618         SILC_NOTIFY_TYPE_LEAVE to its primary router and to the channel.
1619         The channel key MUST also be re-generated when leaving the channel
1620         and distribute it to all clients still currently on the channel.
1621         The key MUST NOT be re-generated if the SILC_CMODE_PRIVKEY mode
1622         is set.
1623
1624         Reply messages to the command:
1625
1626         Max Arguments:  2
1627             Arguments:  (1) <Status Payload>  (2) <Channel ID>
1628
1629         The <Channel ID> is the ID of left channel.
1630
1631         Status messages:
1632
1633             SILC_STATUS_OK
1634             SILC_STATUS_ERR_NOT_REGISTERED
1635             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
1636             SILC_STATUS_ERR_TOO_MANY_PARAMS
1637             SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
1638             SILC_STATUS_ERR_BAD_CHANNEL_ID
1639             SILC_STATUS_ERR_NO_CHANNEL_ID
1640
1641
1642    25   SILC_COMMAND_USERS
1643
1644         Max Arguments:  2
1645             Arguments:  (1) [<Channel ID>]  (2) [<channel name>]
1646
1647         This command is used to list user names currently on the requested
1648         channel; either the argument <Channel ID> or the <channel name>.
1649         One of these arguments must be present.  The server MUST resolve
1650         the joined clients and reply with a lists of users on the channel
1651         and with list of user modes on the channel.
1652
1653         If the requested channel is a private or secret channel, this
1654         command MUST NOT send the list of users, but error is returned
1655         to the sender, except if the sender is on the channel, or the
1656         sender is server.
1657
1658         Reply messages to the command:
1659
1660         Max Arguments:  5
1661             Arguments:  (1) <Status Payload>  (2) <Channel ID>
1662                         (3) <list count>      (4) <Client ID list>
1663                         (5) <client mode list>
1664
1665         This command replies with the Channel ID of the requested channel
1666         Client ID list of the users on the channel and list of their modes.
1667         The Client ID list has Client ID's of all users in the list.  The
1668         <Client ID list> is formed by adding Client ID's one after another.
1669         The <client mode list> is formed by adding client's user modes on
1670         the channel one after another (4 bytes (32 bits) each).  The <list
1671         count> of length of 4 bytes (32 bits), tells the number of entries
1672         in the lists.  Both lists MUST have equal number of entries.
1673
1674         Status messages:
1675
1676             SILC_STATUS_OK
1677             SILC_STATUS_ERR_NOT_REGISTERED
1678             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
1679             SILC_STATUS_ERR_TOO_MANY_PARAMS
1680             SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
1681             SILC_STATUS_ERR_BAD_CHANNEL_ID
1682             SILC_STATUS_ERR_NO_CHANNEL_ID
1683             SILC_STATUS_ERR_NOT_ON_CHANNEL
1684
1685
1686    26   SILC_COMMAND_GETKEY
1687
1688         Max Arguments:  1
1689             Arguments:  (1) <ID Payload>
1690
1691         This command is used to fetch the public key of the client or
1692         server indicated by the <ID Payload>.  The public key is fetched
1693         from the server where to the client is connected.
1694
1695         Reply messages to the command:
1696
1697         Max Arguments:  3
1698             Arguments:  (1) <Status Payload>      (2) <ID Payload>
1699                         (3) [<Public Key Payload>]
1700
1701         This command replies with the client's or server's ID and with
1702         the <Public Key Payload>.
1703
1704         Status messages:
1705
1706             SILC_STATUS_OK
1707             SILC_STATUS_ERR_NOT_REGISTERED
1708             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
1709             SILC_STATUS_ERR_TOO_MANY_PARAMS
1710             SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
1711             SILC_STATUS_ERR_NO_SUCH_SERVER_ID
1712
1713
1714    27   SILC_COMMAND_SERVICE
1715
1716         Max Arguments:  256
1717             Arguments:  (1) [<service name>]    (2) [<auth payload>]
1718                         (n) [...]
1719
1720         This command is used to negotiate a service agreement with a
1721         remote server.  If this command is given without arguments it
1722         MAY return the service list, if it is publicly available.  The
1723         <service name> is a service sepcific identifier, and the
1724         <auth payload> MAY be used to authenticate the requestor to the
1725         remote service.  The authentication to a service may be based
1726         on previous agreement with the requestor and the service
1727         provider.  The command MAY also take additional service
1728         specific arguments.
1729
1730         This document does not specify any services.  How the services
1731         are configured and put available in a server is also out of
1732         scope of this document.
1733
1734         This command MAY be used by client to start using some service
1735         in a server, but it also MAY be used by server to negotiate
1736         to start using a service in some other server or router.
1737
1738         After the negotiation is done both of the parties need to know
1739         from the service identifier how the service can be used.  The
1740         service can be considered to be a protocol which both of the
1741         parties need to support.
1742
1743         Reply messages to the command:
1744
1745         Max Arguments:  256
1746             Arguments:  (1) <Status Payload>      (2) [<service list>]
1747                         (3) [<service name>]      (n) [...]
1748
1749
1750         This command MAY reply with the <service list> when command is
1751         given without arguments, and the list is a comma separated list
1752         of service identifiers.  The <service name> is the service that
1753         the sender requested and this is provided when the server has
1754         accepted the sender to use the <service name>.  The command
1755         reply MAY also have additional service specific arguments.
1756
1757         Status messages:
1758
1759             SILC_STATUS_OK
1760             SILC_STATUS_ERR_NOT_REGISTERED
1761             SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
1762             SILC_STATUS_ERR_TOO_MANY_PARAMS
1763             SILC_STATUS_ERR_NO_SUCH_SERVICE
1764             SILC_STATUS_ERR_AUTH_FAILED
1765             SILC_STATUS_ERR_PERM_DENIED
1766
1767
1768    28 - 199
1769
1770         Currently undefined commands.
1771
1772
1773    200 - 254
1774
1775         These commands are reserved for private use and will not be defined
1776         in this document.
1777
1778
1779    255  SILC_COMMAND_MAX
1780
1781         Reserved command.  This must not be sent.
1782 .in 3
1783
1784
1785 .ti 0
1786 2.3.1 SILC Command Status Payload
1787
1788 Command Status Payload is sent in command reply messages to indicate
1789 the status of the command.  The payload is one of argument in the
1790 command thus this is the data area in Command Argument Payload described
1791 in [SILC2].  The payload is only 2 bytes of length.  The following
1792 diagram represents the Command Status Payload (field is always in
1793 MSB first order).
1794
1795
1796 .in 21
1797 .nf
1798                      1
1799  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1801 |     Status    |     Error     |
1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1803 .in 3
1804
1805 .ce
1806 Figure 6:  SILC Command Status Payload
1807
1808
1809 .in 6
1810 o Status (1 byte) - Indicates the status message type,
1811   error, start of list, entry of list or end of list.
1812
1813 o Error (1 byte) - Indicates the error if the Status
1814   field is some list status, which means there are list
1815   of errors.
1816 .in 3
1817
1818 The values in Status and Error fields are set according
1819 the following rules:
1820
1821 .in 6
1822 o If there is single reply and error has not occurred
1823   then Status field includes value SILC_STATUS_OK, and
1824   the Error field MUST be ignored (and set to zero
1825   value).
1826
1827 o If there is single error, then Status field includes
1828   one of the error values, and the Error field MUST be
1829   ignored (and set to zero value).
1830
1831 o If there will be multiple successful command replies
1832   then Status field includes SILC_STATUS_LIST_START,
1833   SILC_STATUS_LIST_ITEM or SILC_STATUS_LIST_END value,
1834   and Error field is set to SILC_STATUS_OK.
1835
1836 o If there are multiple error replies then Status field
1837   includes SILC_STATUS_LIST_START, SILC_STATUS_LIST_ITEM
1838   or SILC_STATUS_LIST_END value, and the Error field
1839   includes the error value.
1840 .in 3
1841
1842 This way it is possible to send single successful or
1843 single error reply, but also multiple successful and
1844 multiple error replies.  Note that it is possible to
1845 send both list of successful replies and list of error
1846 replies at the same time, however in this case the
1847 list of error replies MUST be sent after the successful
1848 replies.  This way the recipient may ignore the multiple
1849 errors if it wishes to do so.
1850
1851 All Status messages are described in the next section.
1852
1853
1854 .ti 0
1855 2.3.2 SILC Status Types
1856
1857 Status messages are returned in SILC protocol in command reply
1858 packet and in notify packet.  The SILC_PACKET_COMMAND_REPLY is
1859 the command reply packet and status types are sent inside the
1860 Status Payload as one of command reply argument, as defined in
1861 previous sections.  For SILC_PACKET_NOTIFY packet they can be sent
1862 as defined in [SILC2] for SILC_NOTIFY_TYPE_ERROR type.  The same
1863 types defined in this section are used in both cases.
1864
1865 When returning status messages in the command reply message they
1866 indicate whether the command was executed without errors.  If error
1867 occurred the status indicates which error occurred.
1868
1869 When sending status messages in SILC_NOTIFY_TYPE_ERROR notify type
1870 they always send some error status.  Usually they are sent to
1871 indicate that error occurred while processing some SILC packet.
1872 Please see the [SILC1] and [SILC2] for more information sending
1873 status types in SILC_NOTIFY_TYPE_ERROR notify.
1874
1875 The Status Types are only numeric values and the receiver must
1876 convert the numeric values into human readable messages if this
1877 is desired in the application.
1878
1879 List of all defined status types:
1880
1881 .in 0
1882    Generic status messages:
1883
1884    0    SILC_STATUS_OK
1885
1886         Ok status.  Everything went Ok.  The status payload maybe
1887         safely ignored in this case.
1888
1889    1    SILC_STATUS_LIST_START
1890
1891         Start of the list.  There will be several command replies and
1892         this reply is the start of the list.
1893
1894    2    SILC_STATUS_LIST_ITEM
1895
1896         Item in the list.  This is one of the item in the list but not the
1897         first or last one.
1898
1899    3    SILC_STATUS_LIST_END
1900
1901         End of the list.  There were several command replies and this
1902         reply is the last of the list.  There won't be other replies
1903         belonging to this list after this one.
1904
1905    4 - 9
1906
1907         Currently undefined and has been reserved for the future.
1908
1909
1910    Error status message:
1911
1912
1913
1914    10   SILC_STATUS_ERR_NO_SUCH_NICK
1915
1916         "No such nickname".  Requested nickname does not exist.
1917
1918    11   SILC_STATUS_ERR_NO_SUCH_CHANNEL
1919
1920         "No such channel".  Requested channel name does not exist.
1921
1922    12   SILC_STATUS_ERR_NO_SUCH_SERVER
1923
1924         "No such server".  Requested server name does not exist.
1925
1926    13   SILC_STATUS_ERR_TOO_MANY_TARGETS
1927
1928         "Duplicate recipients. No message delivered".  Message were
1929         tried to be sent to recipient which has several occurrences in
1930         the recipient list.
1931
1932    14   SILC_STATUS_ERR_NO_RECIPIENT
1933
1934         "No recipient given".  Command required recipient which was
1935         not provided.
1936
1937    15   SILC_STATUS_ERR_UNKNOWN_COMMAND
1938
1939         "Unknown command".  Command sent to server is unknown by the
1940         server.
1941
1942    16   SILC_STATUS_ERR_WILDCARDS
1943
1944         "Wildcards cannot be used".  Wildcards were provided but they
1945         weren't permitted.
1946
1947    17   SILC_STATUS_ERR_NO_CLIENT_ID
1948
1949         "No Client ID given".  Client ID were expected as command
1950         parameter but were not found.
1951
1952    18   SILC_STATUS_ERR_NO_CHANNEL_ID
1953
1954         "No Channel ID given".  Channel ID were expected as command
1955         parameter but were not found.
1956
1957    19   SILC_STATUS_ERR_NO_SERVER_ID
1958
1959         "No Serve ID given".  Server ID were expected as command
1960         parameter but were not found.
1961
1962    20   SILC_STATUS_ERR_BAD_CLIENT_ID
1963
1964         "Bad Client ID".  Client ID provided were erroneous.
1965
1966    21   SILC_STATUS_ERR_BAD_CHANNEL_ID
1967
1968         "Bad Channel ID".  Channel ID provided were erroneous.
1969
1970    22   SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
1971
1972         "No such Client ID".  Client ID provided does not exist.
1973         The unknown Client ID MUST be provided as next argument
1974         in the reply.
1975
1976    23   SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
1977
1978         "No such Channel ID".  Channel ID provided does not exist.
1979         The unknown Channel ID MUST be provided as next argument
1980         in the reply.
1981
1982    24   SILC_STATUS_ERR_NICKNAME_IN_USE
1983
1984         "Nickname already exists".  Nickname created could not be
1985         registered because number of same nicknames were already set to
1986         maximum.  This is not expected to happen in real life but is
1987         possible to occur.
1988
1989    25   SILC_STATUS_ERR_NOT_ON_CHANNEL
1990
1991         "You are not on that channel".  The command were specified for
1992         channel user is not currently on.
1993
1994    26   SILC_STATUS_ERR_USER_NOT_ON_CHANNEL
1995
1996         "They are not on channel".  The requested target client is not
1997         on requested channel.
1998
1999    27   SILC_STATUS_ERR_USER_ON_CHANNEL
2000
2001         "User already on channel".  User were invited on channel they
2002         already are on.
2003
2004    28   SILC_STATUS_ERR_NOT_REGISTERED
2005
2006         "You have not registered".  User executed command that requires
2007         the client to be registered on the server before it may be
2008         executed.
2009
2010    29   SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
2011
2012         "Not enough parameters".  Command requires more parameters
2013         than provided.
2014
2015    30   SILC_STATUS_ERR_TOO_MANY_PARAMS
2016
2017         "Too many parameters".  Too many parameters were provided
2018         for the command.
2019
2020    31   SILC_STATUS_ERR_PERM_DENIED
2021
2022         "Permission denied".  Generic permission denied error status
2023         to indicate disallowed access.
2024
2025    32   SILC_STATUS_ERR_BANNED_FROM_SERVER
2026
2027         "You are banned from this server".  The client tried to register
2028         on server that has explicitly denied this host to connect.
2029
2030    33   SILC_STATUS_ERR_BAD_PASSWORD
2031
2032         "Cannot join channel. Incorrect password".  Password provided for
2033         channel were not accepted.
2034
2035    34   SILC_STATUS_ERR_CHANNEL_IS_FULL
2036
2037         "Cannot join channel. Channel is full".  The channel is full
2038         and client cannot be joined to it.
2039
2040    35   SILC_STATUS_ERR_NOT_INVITED
2041
2042         "Cannot join channel. You have not been invited".  The channel
2043         is invite only channel and client has not been invited.
2044
2045    36   SILC_STATUS_ERR_BANNED_FROM_CHANNEL
2046
2047         "Cannot join channel. You have been banned".  The client has
2048         been banned from the channel.
2049
2050    37   SILC_STATUS_ERR_UNKNOWN_MODE
2051
2052         "Unknown mode".  Mode provided by the client were unknown to
2053         the server.
2054
2055    38   SILC_STATUS_ERR_NOT_YOU
2056
2057         "Cannot change mode for other users".  User tried to change
2058         someone else's mode.
2059
2060    39   SILC_STATUS_ERR_NO_CHANNEL_PRIV
2061
2062         "Permission denied. You are not channel operator".  Command may
2063         be executed only by channel operator.
2064
2065    40   SILC_STATUS_ERR_NO_CHANNEL_FOPRIV
2066
2067         "Permission denied. You are not channel founder".  Command may
2068         be executed only by channel operator.
2069
2070    41   SILC_STATUS_ERR_NO_SERVER_PRIV
2071
2072         "Permission denied. You are not server operator".  Command may
2073         be executed only by server operator.
2074
2075    42   SILC_STATUS_ERR_NO_ROUTER_PRIV
2076
2077         "Permission denied. You are not SILC operator".  Command may be
2078         executed only by router (SILC) operator.
2079
2080    43   SILC_STATUS_ERR_BAD_NICKNAME
2081
2082         "Bad nickname".  Nickname requested contained illegal characters
2083         or were malformed.
2084
2085    44   SILC_STATUS_ERR_BAD_CHANNEL
2086
2087         "Bad channel name".  Channel requested contained illegal characters
2088         or were malformed.
2089
2090    45   SILC_STATUS_ERR_AUTH_FAILED
2091
2092         "Authentication failed".  The authentication data sent as
2093         argument were wrong and thus authentication failed.
2094
2095    46   SILC_STATUS_ERR_UNKOWN_ALGORITHM
2096
2097         "The algorithm was not supported."  The server does not support the
2098         requested algorithm.
2099
2100    47   SILC_STATUS_ERR_NO_SUCH_SERVER_ID
2101
2102         "No such Server ID".  Server ID provided does not exist.
2103         The unknown Server ID MUST be provided as next argument
2104         in the reply.
2105
2106    49   SILC_STATUS_ERR_NO_SUCH_SERVICE
2107
2108         "Service does not exist".  Requested service identifier is
2109         unknown.
2110
2111 .in 3
2112
2113
2114 .ti 0
2115 3 Security Considerations
2116
2117 Security is central to the design of this protocol, and these security
2118 considerations permeate the specification.  Common security considerations
2119 such as keeping private keys truly private and using adequate lengths for
2120 symmetric and asymmetric keys must be followed in order to maintain the
2121 security of this protocol.
2122
2123
2124 .ti 0
2125 4 References
2126
2127 [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
2128              Protocol Specification", Internet Draft, April 2001.
2129
2130 [SILC2]      Riikonen, P., "SILC Packet Protocol", Internet Draft,
2131              April 2001.
2132
2133 [SILC3]      Riikonen, P., "SILC Key Exchange and Authentication
2134              Protocols", Internet Draft, April 2001.
2135
2136 [IRC]        Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
2137              RFC 1459, May 1993.
2138
2139 [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
2140              April 2000.
2141
2142 [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
2143              2811, April 2000.
2144
2145 [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
2146              2812, April 2000.
2147
2148 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
2149              2813, April 2000.
2150
2151 [SSH-TRANS]  Ylonen, T., et al, "SSH Transport Layer Protocol",
2152              Internet Draft.
2153
2154 [PGP]        Callas, J., et al, "OpenPGP Message Format", RFC 2440,
2155              November 1998.
2156
2157 [SPKI]       Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
2158              September 1999.
2159
2160 [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
2161              Infrastructure, Certificate and CRL Profile", RFC 2459,
2162              January 1999.
2163
2164 [Schneier]   Schneier, B., "Applied Cryptography Second Edition",
2165              John Wiley & Sons, New York, NY, 1996.
2166
2167 [Menezes]    Menezes, A., et al, "Handbook of Applied Cryptography",
2168              CRC Press 1997.
2169
2170 [OAKLEY]     Orman, H., "The OAKLEY Key Determination Protocol",
2171              RFC 2412, November 1998.
2172
2173 [ISAKMP]     Maughan D., et al, "Internet Security Association and
2174              Key Management Protocol (ISAKMP)", RFC 2408, November
2175              1998.
2176
2177 [IKE]        Harkins D., and Carrel D., "The Internet Key Exchange
2178              (IKE)", RFC 2409, November 1998.
2179
2180 [HMAC]       Krawczyk, H., "HMAC: Keyed-Hashing for Message
2181              Authentication", RFC 2104, February 1997.
2182
2183 [PKCS1]      Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
2184              Specifications, Version 2.0", RFC 2437, October 1998.
2185
2186 [RFC2119]    Bradner, S., "Key Words for use in RFCs to Indicate
2187              Requirement Levels", BCP 14, RFC 2119, March 1997.
2188
2189 [RFC2279]    Yergeau, F., "UTF-8, a transformation format of ISO
2190              10646", RFC 2279, January 1998.
2191
2192
2193
2194
2195
2196 .ti 0
2197 5 Author's Address
2198
2199 .nf
2200 Pekka Riikonen
2201 Snellmanninkatu 34 A 15
2202 70100 Kuopio
2203 Finland
2204
2205 EMail: priikone@iki.fi
2206
2207 This Internet-Draft expires XXX
2208
2209
2210 .ti 0
2211 Appendix A
2212
2213 This appendix defines the usage of the <Requested Attributes> argument in
2214 the SILC_COMMAND_WHOIS command.  The attributes are defined in [ATTRS],
2215 and may be used to request additional information about the user.  Since
2216 the information that may be requested using the attributes is something
2217 that server cannot deliver to the sender, it is possible to send the WHOIS
2218 command directly to the destination client whom will then provide the
2219 requested attributes.  This requires the servers to relay the WHOIS
2220 command to the client, and it requires capability for handling the WHOIS
2221 command in the client end.
2222
2223 The <Requested Attributes> MAY include several attributes that are
2224 requested.  The format and encoding of the <Requested Attributes> is as
2225 defined in [ATTRS].  When <Requested Attributes> argument is set the
2226 server MAY process the attributes to see whether it can narrow down
2227 the WHOIS search, for example when searching with a nickname.  The
2228 normal servers MUST process the WHOIS command as normal WHOIS command,
2229 that is to send the command directly to the router.  The router MAY
2230 process the attributes, but it MUST send the command to the server
2231 that owns the requested client.
2232
2233 The server that owns the client and receives the command MUST check
2234 whether the client is detached from the network.  If it is detached,
2235 that is the user mode has the SILC_UMODE_DETACHED mode set, it SHOULD
2236 process the attributes and provide as many of the requested attributes
2237 as possible and then send reply back to the sender.  If the client is
2238 active in the network it MUST send the command to the client for
2239 processing.
2240
2241 The client receiving WHOIS command SHOULD check whether the
2242 <Requested Attributes> argument is set.  If it is not set then the
2243 WHOIS command SHOULD be discarded.  The client processes the requested
2244 attributes and SHOULD reply to each of the requested attribute with
2245 either valid value, or with an indication that the requested attribute
2246 is not known or supported.  This is to be done as defined in [ATTRS].
2247 The client always MUST send a reply to the command when some attributes
2248 were requested.  The client MAY also add additional attributes to the
2249 reply even if they were not requested.  The client MAY also digitally
2250 sign the attributes with ATTRIBUTE_USER_DIGITAL_SIGNATURE as defined
2251 in [ATTRS].  Then the client sends the reply back to the sender of
2252 the command.  The command reply that client assembles does not need
2253 to include any other argument but the <Status Payload> (1), and the
2254 <Attributes> (11).  The server receiving reply from client MUST allow
2255 this sort of command reply for WHOIS command.
2256
2257 The information received from the client MAY be cached in the
2258 server's end.  The caching may be desired for example if the client
2259 can be detached from the network.  This way the server is then able
2260 to provide at least partial information for a requestor.  The
2261 server MAY also process the command reply and verify whether the
2262 attributes provided in the reply are actually valid.  If it can do
2263 this, and verify that they indeed are valid values it MAY append
2264 a digital signature at the end of the attributes with the
2265 ATTRIBUTE_SERVER_DIGITAL_SIGNATURE as defined in [ATTRS].  The
2266 server then MUST provide valid WHOIS command reply to the sender
2267 of the command.   Other servers and routers that receive the command
2268 reply enroute to the original sender MAY also cache the information.
2269
2270 The client which receives the command reply to the WHOIS command
2271 SHOULD verify the ATTRIBUTE_USER_DIGITAL_SIGNATURE and the
2272 ATTRIBUTE_SERVER_DIGITAL_SIGNATURE if they are provided.