.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH 25 April 2001
+.ds RH 21 August 2001
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-commands-00.txt 25 April 2001
-Expires: 25 October 2001
+draft-riikonen-silc-commands-01.txt 21 August 2001
+Expires: 21 February 2002
.in 3
.ce 2
SILC Commands
-<draft-riikonen-silc-commands-00.txt>
+<draft-riikonen-silc-commands-01.txt>
.ti 0
Status of this Memo
2.3.1 SILC Command Status Payload ......................... 32
2.3.2 SILC Command Status List ............................ 32
3 Security Considerations ....................................... 37
-4 References .................................................... 37
+4 References .................................................... 38
5 Author's Address .............................................. 39
nicknames in the SILC. The <count> option may be given to narrow
down the number of accepted results. If this is not defined there
are no limit of accepted results. The query may also be narrowed
- down by defining the server name of the nickname.
+ down by defining the server name of the nickname. The <count> is
+ int string format.
It is also possible to search the user by Client ID. If the
<Client ID> is provided server MUST use it as the search value
instead of the <nickname>. One of the arguments MUST be given.
It is also possible to define multiple Client ID's to search
multiple users sending only one WHOIS command. In this case the
- Client ID's are appended as normal arguments. The server replies
- in this case with only one reply message for all requested users.
+ Client ID's are appended as normal arguments.
To prevent miss-use of this command wildcards in the nickname
or in the server name are not permitted. It is not allowed
given to narrow down the number of accepted results. If this
is not defined there are no limit of accepted results. The query
may also be narrowed down by defining the server name of the
- nickname.
+ nickname. The <count> is in string format.
To prevent miss-use of this command wildcards in the nickname
or in the server name are not permitted. The WHOWAS requests MUST
3 SILC_COMMAND_IDENTIFY
Max Arguments: 3328
- Arguments: (1) [<nickname>[@<server>]] (2) [<count>]
- (3) [<Client ID>] (n) [...]
-
- Identify. Identify command is almost analogous to WHOIS command,
- except that it does not return as much information. Only relevant
- information such as Client ID is returned. This is usually used
- to get the Client ID of a client used in the communication with
- the client.
-
- The query may find multiple matching users as there are no unique
- nicknames in the SILC. The <count> option may be given to narrow
- down the number of accepted results. If this is not defined there
- are no limit of accepted results. The query may also be narrowed
- down by defining the server name of the nickname.
-
- It is also possible to search the user by Client ID. If the
- <Client ID> is provided server must use it as the search value
- instead of the <nickname>. One of the arguments must be given.
- It is also possible to define multiple Client ID's to search
- multiple users sending only one IDENTIFY command. In this case
- the Client ID's are appended as normal arguments. The server
- replies in this case with only one reply message for all requested
- users.
-
- To prevent miss-use of this command wildcards in the nickname
- or in the server name are not permitted. It is not allowed
- to request all users on some server. The IDENTIFY requests MUST
- be based on specific nickname request.
+ Arguments: (1) [<nickname>[@<server>]] (2) [<server name>]
+ (3) [<channel name>] (4) [<count>]
+ (5) [<ID Payload>] (n) [...]
+
+ Identify command is used to query information about an entity by
+ the entity's name or ID. This command can be used to query
+ information about clients, server and channels.
+
+ The query may find multiple matching entities. The <count> option
+ may be given to narrow down the number of accepted results. If
+ this is not defined there are no limit of accepted results. The
+ <count> is in string format.
+
+ It is also possible to search the entity by its ID. If the
+ <ID Payload> is provided server must use it as the search value
+ instead of the entity's name. One of the arguments must be given.
+ It is also possible to define multiple ID Payloads to search
+ multiple entities sending only one IDENTIFY command. In this case
+ the ID Payloads are appended as normal arguments. The type of the
+ entity is defined by the type of the ID Payload.
+
+ To prevent miss-use of this command wildcards in the names are
+ not permitted. It is not allowed to request for example all users
+ on server.
Implementations may not want to give interface access to this
- command as it is hardly a command that would be used by an end user.
- However, it must be implemented as it is used with private message
- sending.
+ command as it is hardly a command that would be used by an end
+ user. However, it must be implemented as it is used with private
+ message sending.
- The IDENTIFY MUST be always sent to the router by server so that
- all users are searched. However, server MUST still search its
- locally connected clients.
+ The IDENTIFY command MUST be always sent to the router by server
+ so that all users are searched. However, server MUST still search
+ its locally connected clients.
Reply messages to the command:
Max Arguments: 4
- Arguments: (1) <Status Payload> (2) <Client ID>
- (3) [<nickname>[@<server>]] (4) [<username@host>]
+ Arguments: (1) <Status Payload> (2) <Client ID>
+ (3) [<entity's name>] (4) [<info>]
This command may reply with several command reply messages to form
a list of results. In this case the status payload will include
the last reply to indicate the end of the list. If there are only
one reply the status is set to normal STATUS_OK.
- The command replies with Client ID of the nickname and if more
- information is available it MAY reply with nickname and user name
- and host name. If the <count> option were defined in the query
- there will be only <count> many replies from the server.
+ When querying clients the <entity's name> must include the client's
+ nickname in the following format: nickname>[@server]. The
+ <info> must include the client's username and host in the following
+ format: username@host.
+
+ When querying servers the <entity's name> must include the server's
+ full name. The <info> may be omitted.
+
+ When querying channels the <entity's name> must include the
+ channel's name. The <info> may be omitted.
+
+ If the <count> option were defined in the query there will be only
+ <count> many replies from the server.
Status messages:
SILC_STATUS_LIST_START
SILC_STATUS_LIST_END
SILC_STATUS_ERR_NO_SUCH_NICK
+ SILC_STATUS_ERR_NO_SUCH_SERVER
+ SILC_STATUS_ERR_NO_SUCH_CHANNEL
SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+ SILC_STATUS_ERR_NO_SUCH_SERVER_ID
+ SILC_STATUS_ERR_NO_SUCH_CHANNEL_ID
SILC_STATUS_ERR_WILDCARDS
SILC_STATUS_ERR_NOT_ENOUGH_PARAMS
SILC_STATUS_ERR_TOO_MANY_PARAMS
(3) [<invite list>]
This command replies with the invite list of the channel if it
- exists.
+ exists. The <invite list> may be omitted if the list was not
+ altered.
Status messages:
the requested server.
If the <Server ID> is specified the server information if fetched
- by the provided Server ID.
+ by the provided Server ID. One of the arguments must always be
+ present.
Reply messages to the command:
as operator. The <authentication payload> is the data that the
client is authenticated against. It may be passphrase prompted
for user on client's screen or it may be public key or certificate
- authentication data (data signed with private key).
+ authentication data (data signed with private key). The public
+ key that server will use to verify the signature found in the
+ payload should be verified. It is recommended that the public
+ key is saved locally in the server and server would not use
+ any public keys received during the SKE.
After changing the mode the server MUST send the notify type
SILC_NOTIFY_TYPE_UMODE_CHANGE to its primary router.
method is public key authentication the server MUST NOT
save the authentication data from the payload as the
data is different on all authentications. In this case the
- server only saves the authentication method.
+ server only saves the authentication method. However,
+ server MUST verify the sent authentication payload and
+ set the mode only if the verification was successful.
Note that this mode is effective only in the current server.
The client MUST connect to the same server later to be able
Reply messages to the command:
- Max Arguments: 2
- Arguments: (1) <Status Payload> (2) <channel mode mask>
+ Max Arguments: 3
+ Arguments: (1) <Status Payload> (2) <Channel ID>
+ (3) <channel mode mask>
This command replies with the changed channel mode mask that
client MUST keep locally.
SILC_STATUS_ERR_NO_CHANNEL_PRIV
SILC_STATUS_ERR_UNKNOWN_MODE
SILC_STATUS_ERR_NO_SUCH_CLIENT_ID
+ SILC_STATUS_ERR_AUTH_FAILED
18 SILC_COMMAND_CUMODE
However, if the SILC_CMODE_FOUNDER_AUTH channel mode has
been set, the client can claim channel founder privileges
by providing the <auth payload> that the server will use
- to authenticate the client. The client MAY remove this
- mode at any time.
+ to authenticate the client. The public key that server will
+ use to verify the <auth payload> must the same public key
+ that was saved when the SILC_CMODE_FOUNDER_AUTH channel
+ mode was set. The client MAY remove this mode at any time.
0x0002 SILC_CUMODE_OPERATOR
Reply messages to the command:
- Max Arguments: 3
+ Max Arguments: 4
Arguments: (1) <Status Payload> (2) <channel user mode mask>
- (3) <Client ID>
+ (3) <Channel ID> (4) <Client ID>
This command replies with the changed channel user mode mask that
- client MUST keep locally. The <Client ID> is the target client.
+ client MUST keep locally. The <Channel ID> is the specified
+ channel. The <Client ID> is the target client.
Status messages:
as operator. The <authentication payload> is the data that the
client is authenticated against. It may be passphrase prompted
for user on client's screen or it may be public key or certificate
- authentication data (data signed with private key).
+ authentication data (data signed with private key). The public
+ key that router will use to verify the signature found in the
+ payload should be verified. It is recommended that the public
+ key is saved locally in the router and router would not use
+ any public keys received during the SKE.
Difference between router operator and server operator is that
router operator is able to handle cell level properties while
25 SILC_COMMAND_USERS
- Max Arguments: 1
- Arguments: (1) <Channel ID>
+ Max Arguments: 2
+ Arguments: (1) [<Channel ID>] (2) [<channel name>]
This command is used to list user names currently on the requested
- channel; argument <Channel ID>. The server MUST resolve the
- user names and send a comma (`,') separated list of user names
+ channel; either the argument <Channel ID> or the <channel name>.
+ One of these arguments must be present. The server MUST resolve
+ the user names and send a comma (`,') separated list of user names
on the channel. Server or router MAY resolve the names by sending
SILC_COMMAND_WHOIS or SILC_COMMAND_IDENTIFY commands.
Max Arguments: 3
Arguments: (1) <Status Payload> (2) <ID Payload>
- (3) <Public Key Payload>
+ (3) [<Public Key Payload>]
This command replies with the client's or server's ID and with
the <Public Key Payload>.
.nf
Pekka Riikonen
-Kasarmikatu 11 A4
-70110 Kuopio
+Snellmanninkatu 34 A 15
+70100 Kuopio
Finland
-EMail: priikone@poseidon.pspt.fi
+EMail: priikone@silcnet.org
-This Internet-Draft expires 25 October 2001
+This Internet-Draft expires 21 February 2002
+
projects / crypto.git / blobdiff