ID's can be sent as arguments.
All passphrases that may be sent in commands as arguments MUST be
-UTF-8 [RFC2279] encoded. All strings, with exeption of nicknames and
-channel names [SILC1], are UTF-8 encoded. This includes strings like
-algorithm names, quit, kick and kill messages, service identifiers and
-others.
+UTF-8 [RFC3629] encoded. All strings sent as arguments in command and
+command reply are also UTF-8 encoded, unless otherwise defined. See
+the [SILC1] for general UTF-8 definition in SILC protocol.
All public keys and certificates that are sent as arguments are actually
Public Key Payloads [SILC2]. This way it is possible to send different
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>. 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
+ instead of the <nickname>. 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 <Requested Attributes> is defined in [ATTRS] and can be used
to request all users on some server. The WHOIS requests MUST
be based on explicit nickname request.
- The WHOIS request MUST be always sent to the router by normal
- server so that all users are searched. However, the server still
+ The WHOIS request MUST be always sent to the router by normal
+ server so that all users are searched. However, the server still
MUST search its locally connected clients. The router MUST send
this command to the server which owns the requested client, if
the router is unable to provide all mandatory information about
Arguments: (1) <nickname>
Set/change nickname. This command is used to set nickname for
- user. Nickname MUST NOT include any whitespaces (` '),
- non-printable characters, commas (`,'), '@', '!' or any wildcard
- characters.
+ user. See [SILC1] for definition of correctly formatted
+ nickname.
When nickname is changed new Client ID is generated. Server MUST
distribute SILC_NOTIFY_TYPE_NICK_CHANGE to local clients on the
created. If server is normal server this command MUST be sent
to router which will create the channel. The channel MAY be
protected with passphrase. If this is the case the passphrase
- MUST be sent along the join command.
-
- The name of the <channel> MUST NOT include any spaces (` '),
- non-printable characters, commas (`,') or any wildcard characters.
+ MUST be sent along the join command. See the [SILC1] for
+ definition of correctly formatted channel name, <channel>.
The second argument <Client ID> is the Client ID of the client
which is joining to the client. When client sends this command
remote service. The authentication to a service may be based
on previous agreement with the requester and the service
provider. The command MAY also take additional service
- specific arguments. The <service name> is UTF-8 string.
+ specific arguments.
This document does not specify any services. How the services
are configured and put available in a server is also out of
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
-[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
+[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629, November 2003.
[ATTRS] Riikonen, P., "User Online Presence and Information
Attributes", Internet Draft, May 2002.
arguments to be sent along the notify message.
.in 3
-The following list of currently defined notify types. The format for
+Following the list of currently defined notify types. The format for
notify arguments is same as in SILC commands described in [SILC4].
Note that all IDs sent in arguments are sent inside ID Payload. Also
-note that all passphrases that may be sent inside arguments MUST be
-UTF-8 [RFC2279] encoded. Also note that all public keys or certificates
-sent inside arguments are actually Public Key Payloads.
+note that all strings sent as arguments MUST be UTF-8 [RFC3629] encoded,
+unless otherwise defined. Also note that all public keys or
+certificates sent inside arguments are actually Public Key Payloads.
.in 6
Max Arguments: 1
Arguments: (1) <message>
- The <message> is implementation specific free UTF-8 text string.
+ The <message> is implementation specific free text string.
Receiver MAY ignore this message.
is sent to local servers on the channel, but MUST NOT be sent
to clients on the channel. Router MUST broadcast this to its
primary router and to local servers on the channel. When a client
- was directly invited to the channel this is also sent to that
+ was directly invited to the channel this is also sent to that
client. In this case the packet is destined to the client.
Max Arguments: 5
The <invite list> format is defined in [SILC4] with
SILC_COMMAND_INVITE command. When this notify is destined to
a client the <add | del> and <invite list> MUST NOT be sent.
- When <add | del> is used to announce information during server
+ When <add | del> is used to announce information during server
connecting phase the argument type MUST be 0x03. See section
4.2.1 in [SILC1] for more information.
Arguments: (1) <motd>
The <motd> is the Message of the Day. This notify MAY be
- ignored.
+ ignored and is OPTIONAL.
10 SILC_NOTIFY_TYPE_CHANNEL_CHANGE
(3) <Kicker's Client ID>
The <Client ID> is the client which was kicked from the channel.
- The kicker may have set the <comment> to indicate the reason for
- the kicking. The <Kicker's Client ID> is the kicker.
+ The kicker may have set the <comment> string to indicate the
+ reason for the kicking. The <Kicker's Client ID> is the kicker.
13 SILC_NOTIFY_TYPE_KILLED
(3) <Killer's ID>
The <Client ID> is the client which was killed from the network.
- The killer may have set the <comment> to indicate the reason for
- the killing. The <Killer's ID> is the killer, which may be
- client but also router server.
+ The killer may have set the <comment> string to indicate the
+ reason for the killing. The <Killer's ID> is the killer, which
+ may be client but also router server.
14 SILC_NOTIFY_TYPE_UMODE_CHANGE
from ban list. The <ban list> indicates the information to be
added to or removed from the ban list. The <ban list> format
format is defined in [SILC4] with SILC_COMMAND_BAN command.
- When <add | del> is used to announce information during server
+ When <add | del> is used to announce information during server
connecting phase the argument type MUST be 0x03. See section
4.2.1 in [SILC1] for more information.
.in 6
o Error Message (variable length) - Human readable error
- message as UTF-8 string.
+ message.
.in 3
Hostname field.
o Hostname (variable length) - The hostname or IP address where
- the SKE protocol is running. The sender MAY fill this field
- when sending the payload. If the receiver sends this payload
- as reply to the request it MUST fill this field.
+ the SKE protocol is running, as UTF-8 encoded string. The sender
+ MAY fill this field when sending the payload. If the receiver
+ sends this payload as reply to the request it MUST fill this field.
o Port (4 bytes) - The port where the SKE protocol is bound.
The sender MAY fill this field when sending the payload. If
[SFTP] Ylonen T., and Lehtinen S., "Secure Shell File Transfer
Protocol", Internet Draft, March 2001.
-[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
+[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629, November 2003.
.ti 0
3.10.5 Compression Algorithms ............................. 28
3.11 SILC Public Key .......................................... 29
3.12 SILC Version Detection ................................... 31
- 3.13 Backup Routers ........................................... 31
- 3.13.1 Switching to Backup Router ......................... 33
- 3.13.2 Resuming Primary Router ............................ 34
+ 3.13 UTF-8 Strings in SILC .................................... XXXX
+ 3.13.1 UTF-8 Nicknames and Channel Names .................. XXXX
+ 3.14 Backup Routers ........................................... 31
+ 3.14.1 Switching to Backup Router ......................... 33
+ 3.14.2 Resuming Primary Router ............................ 34
4 SILC Procedures ............................................... 36
4.1 Creating Client Connection ................................ 37
4.2 Creating Server Connection ................................ 38
identify specific users when sending messages. This feature of SILC
makes IRC style nickname-wars obsolete as no one owns their nickname;
there can always be someone else with the same nickname. Also, any kind
-of nickname registering service becomes obsolete. The maximum length of
-nickname is 128 bytes.
+of nickname registering service becomes obsolete. See the section 3.13.1
+for more information about nicknames.
.ti 0
truncated taking 88 bits from the start of the hash value.
This hash value is used to search the user's Client ID
from the ID lists. Note that the nickname MUST be in
- lowercase format.
+ lowercase format before computing the hash value. Since
+ nicknames are UTF-8 encoded, some characters cannot be
+ converted to lower case. All characters that has a
+ lowercase alternative in the Unicode standard MUST be
+ converted to lowercase.
.in 3
Collisions could occur when more than 2^8 clients using same nickname
Channel names are unique although the real uniqueness comes from 64 bit
Channel ID. However, channel names are still unique and no two global
-channels with same name may exist. The channel name is a string of
-maximum length of 256 bytes. Channel names MUST NOT contain any
-whitespaces (` '), any non-printable ASCII characters, commas (`,')
-and wildcard characters.
+channels with same name may exist. See the section 3.13.1 for more
+information about channel names.
-Channels can have operators that can administrate the channel and
-operate all of its modes. The following operators on channel exist on
-the SILC network.
+Channels can have operators that can administrate the channel and operate
+all of its modes. The following operators on channel exist on the
+SILC network.
.in 6
o Channel founder - When channel is created the joining client becomes
REQUIRED to use authentication protocol when connecting. The
authentication may be based on passphrase (pre-shared secret) or public
key based on digital signatures. All passphrases sent in SILC protocol
-MUST be UTF-8 [RFC2279] encoded. The connection authentication protocol
+MUST be UTF-8 [RFC3629] encoded. The connection authentication protocol
is described in detail in [SILC3].
.ti 0
-3.13 Backup Routers
+3.13 UTF-8 Strings in SILC
+
+By default all strings that are sent in SILC protocol MUST be UTF-8
+[RFC3269] encoded, unless otherwise defined. This means that any string
+sent inside, for example, command, command reply, notify or any packet
+payload is UTF-8 encoded. Also nicknames, channel names, server names,
+and hostnames are UTF-8 encoded. This definition does not affect
+messages sent in SILC, as the Message Payload provides its own mechanism
+to indicate whether a message is UTF-8 text message, data message, which
+might use its own character encoding, or pure binary message [SILC2].
+
+Certain limitations are imposed on the UTF-8 encoded strings in SILC.
+The UTF-8 encoded strings MUST NOT include any characters that are
+marked in the Unicode standard as control codes, Unicode noncharacters,
+reserved or private range characters, or any other illegal Unicode
+characters. Also the BOM (Byte-Order Mark) MUST NOT be used as byte
+order signature in UTF-8 encoded strings.
+
+Because of these limitations on the UTF-8 encoded strings the
+implementation may need to have access to full Unicode implementation
+to be able to validate the contents of the strings. This is especially
+important in server implementation because server must verify that,
+for example, nicknames does not include any prohibited characters.
+Server also need to have the capability to convert character case from
+upper case to lower case characters, when applicable.
+
+On user interface where UTF-8 strings are displayed the implementation
+is RECOMMENDED to escape any character that it is unable to render
+properly. The escaping may be done for example as described in
+[RFC2253].
+
+
+.ti 0
+3.13.1 UTF-8 Nicknames and Channel Names
+
+The nicknames and channel names are also UTF-8 encoded in SILC protocol.
+As these strings may be used as message destination indicator on the
+user interface certain additional limitations has been imposed to it.
+In addition of general UTF-8 string limitations described in previous
+section, the UTF-8 encoded nickname and channel name strings MUST NOT
+include any characters that has been marked in the Unicode standard as
+space (white space) characters, line and paragraph separators,
+mathematical and currency symbol characters, or any other symbol
+characters, special characters or tags. In addition nicknames and
+channel names MUST NOT include commas (','), '@', '!' or any wildcard
+characters.
+
+This definition means that these strings generally may only include
+letters, numbers, most punctuation characters and some other characters.
+For practical reasons all symbol characters and many other special
+characters are prohibited. Conforming implementation MUST treat
+strings with prohibited characters as malformed strings.
+
+The length of a nickname string in SILC MUST NOT exceed 128 bytes.
+The length of a channel name string in SILC MUST NOT exceed 256 bytes.
+Since these strings are UTF-8 encoded the length of one character
+may be longer than one byte. This means that the character length
+of these strings may be shorter than the maximum length of the string
+in bytes. The minimum length of these strings MUST be at least one
+character, which may be one byte or more in length.
+
+
+.ti 0
+3.14 Backup Routers
Backup routers may exist in the cell in addition to the primary router.
However, they must not be active routers or act as routers in the cell.
.ti 0
-3.13.1 Switching to Backup Router
+3.14.1 Switching to Backup Router
When the primary router of the cell becomes unresponsive, for example
by sending EOF to the connection, all the parties of this protocol MUST
.ti 0
-3.13.2 Resuming Primary Router
+3.14.2 Resuming Primary Router
Usually the primary router is unresponsive only a short period of time
and it is intended that the original router of the cell will resume
SILC_NOTIFY_TOPIC_SET notify type into the SILC_PACKET_NOTIFY packet.
Also, channel's invite and ban lists MUST be announced by compiling list
of Notify Payloads with the SILC_NOTIFY_TYPE_INVITE and
-SILC_NOTIFY_TYPE_BAN notify types, respectively, into the
+SILC_NOTIFY_TYPE_BAN notify types, respectively, into the
SILC_PACKET_NOTIFY packet.
The router which receives these lists MUST process them and broadcast
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
-[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
+[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629, November 2003.
[RFC1321] Rivest R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
projects / silc.git / commitdiff