.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH XXX
+.ds RH 15 May 2002
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-commands-03.txt XXX
-Expires: XXX
+draft-riikonen-silc-commands-03.txt 15 May 2002
+Expires: 15 November 2002
.in 3
2 SILC Commands ................................................. 2
2.1 SILC Commands Syntax ...................................... 2
2.2 SILC Commands List ........................................ 4
- 2.3 SILC Command Status Payload ............................... 33
-3 SILC Status Types ............................................. 33
-4 Security Considerations ....................................... 38
-5 References .................................................... 38
-6 Author's Address .............................................. 40
-Appendix A ...................................................... xx
+ 2.3 SILC Command Status Payload ............................... 40
+3 SILC Status Types ............................................. 41
+4 Security Considerations ....................................... 47
+5 References .................................................... 47
+6 Author's Address .............................................. 49
+Appendix A ...................................................... 49
.ti 0
include STATUS_LIST_START status in the first reply and
STATUS_LIST_END in the last reply to indicate the end of the
list. If there are only one reply the status is set to normal
- STATUS_OK.
+ STATUS_OK. If multiple Client IDs was requested then each found
+ and unfound client must cause successful or error reply,
+ respectively.
The command replies include the Client ID of the nickname,
nickname and server name, user name and host name and user's real
The server also returns client's user mode, idle time, and the
fingerprint of the client's public key. The <fingerprint> is the
binary hash digest of the public key. The fingerprint MUST NOT
- be sent if the server has not verified the proof of posession of
+ be sent if the server has not verified the proof of possession of
the corresponding private key. Server can do this during the
SILC Key Exchange protocol. The <fingerprint> is SHA1 digest.
a list of results. In this case the status payload will include
STATUS_LIST_START status in the first reply and STATUS_LIST_END in
the last reply to indicate the end of the list. If there are only
- one reply the status is set to normal STATUS_OK.
+ one reply the status is set to normal STATUS_OK. If multiple Client
+ IDs was requested then each found and unfound client must cause
+ successful or error reply, respectively.
When querying clients the <entity's name> must include the client's
nickname in the following format: nickname[@server]. The
privileges the same way as the client had given the
SILC_COMMAND_CUMODE command to gain founder privileges. The
client is still able to join the channel even if the founder
- privileges could not be gained.
+ privileges could not be gained. The hash function used with
+ the <founder payload> MUST be sha1.
The server MUST check whether the user is allowed to join to
the requested channel. Various modes set to the channel affect
0x00000100 SILC_UMODE_ANONYMOUS
Marks that the client is anonymous client. Server
- that specificly is designed for anonymous services
+ that specifically is designed for anonymous services
can set and unset this mode. Client MUST NOT set or
unset this mode itself. A client with this mode set
would have the username and the hostname information
of a channel. Modes may be masked together by ORing them thus
having several modes set. The <Channel ID> is the ID of the
target channel. The client changing channel mode MUST be on
- the same channel and poses sufficient privileges to be able to
+ the same channel and posses sufficient privileges to be able to
change the mode.
When the mode is changed SILC_NOTIFY_TYPE_CMODE_CHANGE notify
used to verify the payload is the public key of the
client sending this command. The mode may be set only
if the <auth payload> was verified successfully. The
- server also MUST save the founder's public key.
+ server also MUST save the founder's public key. The
+ hash function used with the <auth payload> MUST be sha1.
The public key of the founder is sent in the
SILC_NOTIFY_TYPE_CMODE_CHANGE notify type so that other
The <Channel ID> is the ID of the target channel. The <mode mask>
is OR'ed mask of modes. The <Client ID> is the target client.
The client changing channel user modes MUST be on the same channel
- as the target client and poses sufficient privileges to be able to
+ as the target client and posses sufficient privileges to be able to
change the mode.
When the mode is changed SILC_NOTIFY_TYPE_CUMODE_CHANGE notify
SILC_STATUS_ERR_NO_CLIENT_ID
+
+
20 SILC_COMMAND_BAN
Max Arguments: 3
SILC_STATUS_ERR_RESOURCE_LIMIT
+
+
21 SILC_COMMAND_DETACH
Max Arguments: 0
channel; either the argument <Channel ID> or the <channel name>.
One of these arguments must be present. The server MUST resolve
the joined clients and reply with a lists of users on the channel
- and with list of user modes on the channel.
+ and with list of user modes on the channel.
If the requested channel is a private or secret channel, this
command MUST NOT send the list of users, but error is returned
This command is used to negotiate a service agreement with a
remote server. If this command is given without arguments it
MAY return the service list, if it is publicly available. The
- <service name> is a service sepcific identifier, and the
- <auth payload> MAY be used to authenticate the requestor to the
+ <service name> is a service specific identifier, and the
+ <auth payload> MAY be used to authenticate the requester to the
remote service. The authentication to a service may be based
- on previous agreement with the requestor and the service
+ on previous agreement with the requester and the service
provider. The command MAY also take additional service
specific arguments.
SILC_STATUS_ERR_PERM_DENIED
+
+
28 - 199
Currently undefined commands.
replies at the same time, however in this case the
list of error replies MUST be sent after the successful
replies. This way the recipient may ignore the multiple
-errors if it wishes to do so.
+errors if it wishes to do so. Also note that in this
+case the successful and error replies belong to the
+same list.
All Status messages are described in the next section.
4 References
[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
- Protocol Specification", Internet Draft, April 2001.
+ Protocol Specification", Internet Draft, May 2002.
[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
- April 2001.
+ May 2002.
[SILC3] Riikonen, P., "SILC Key Exchange and Authentication
- Protocols", Internet Draft, April 2001.
+ Protocols", Internet Draft, May 2002.
[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
RFC 1459, May 1993.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
-
-
+[ATTRS] Riikonen, P., "User Online Presence and Information
+ Attributes", Internet Draft, May 2002.
.ti 0
.nf
Pekka Riikonen
-Snellmanninkatu 34 A 15
+Snellmaninkatu 34 A 15
70100 Kuopio
Finland
EMail: priikone@iki.fi
-This Internet-Draft expires XXX
+This Internet-Draft expires 15 November 2002
.ti 0
The information received from the client MAY be cached in the
server's end. The caching may be desired for example if the client
can be detached from the network. This way the server is then able
-to provide at least partial information for a requestor. The
+to provide at least partial information for a requester. The
server MAY also process the command reply and verify whether the
attributes provided in the reply are actually valid. If it can do
this, and verify that they indeed are valid values it MAY append
ATTRIBUTE_SERVER_DIGITAL_SIGNATURE as defined in [ATTRS]. The
server then MUST provide valid WHOIS command reply to the sender
of the command. Other servers and routers that receive the command
-reply enroute to the original sender MAY also cache the information.
+reply en route to the original sender MAY also cache the information.
The client which receives the command reply to the WHOIS command
SHOULD verify the ATTRIBUTE_USER_DIGITAL_SIGNATURE and the
projects / silc.git / blobdiff