.in 16
.nf
- S/R1 - > - > - > - > - > - > - S/R2
+ S/R1 - < - < - < - < - < - < - S/R2
\\ /
- ^ v
- \\ - < - < - S/R3 - < - < - /
+ v ^
+ \\ - > - > - S/R3 - > - > - /
.in 3
to be used along with the nicknames to 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. The maximum length of nickname is 128 characters.
+nickname. The maximum length of nickname is 128 bytes.
.ti 0
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 characters. Channel names MUST NOT contain any
+maximum length of 256 bytes. Channel names MUST NOT contain any
spaces (` '), any non-printable ASCII characters, commas (`,') and
wildcard characters.
client connecting to the server. However, usually clients are accepted
to connect to server without explicit authentication. Servers are
required use authentication protocol when connecting. The authentication
-may be based on passphrase (pre-shared-secret) or public key. The
-connection authentication protocol is described in detail in [SILC3].
+may be based on passphrase (pre-shared-secret) or public key. All
+passphrases sent in SILC protocol MUST be UTF-8 [RFC2279] encoded.
+The connection authentication protocol is described in detail in [SILC3].
.ti 0
If the authentication method is password based, the Authentication
-Data field includes the plaintext password. It is safe to send
-plaintext password since the entire payload is encrypted. In this
-case the Public Data Length is set to zero (0), but MAY also include
+Data field includes the plaintext UTF-8 encoded password. It is safe
+to send plaintext password since the entire payload is encrypted. In
+this case the Public Data Length is set to zero (0), but MAY also include
random data for padding purposes. It is also RECOMMENDED that maximum
amount of padding is applied to SILC packet when using password based
authentication. This way it is not possible to approximate the length
.in 6
protocol version = <major>.<minor>
-software version = <major>[.<minor>[.<build>]]
+software version = <major>[.<minor>[.<build or vendor string>]]
.in 3
Protocol version MAY provide both major and minor version. Currently
-implementations MUST set the protocol version and accept the protocol
-version as SILC-1.0-<software version>. If new protocol version causes
-in compatibilities with older version the the <minor> versio number MUST
-be incremented. The <major> is incremented if new protocol version is
-fully incompatible.
+implementations MUST set the protocol version and accept at least the
+protocol version as SILC-1.1-<software version>. If new protocol version
+causes in compatibilities with older version the the <minor> versio number
+MUST be incremented. The <major> is incremented if new protocol version
+is fully incompatible.
-Software version MAY provide major, minor and build version. The
-software version MAY be freely set and accepted.
+Software version MAY provide major, minor and build (vendor) version.
+The software version MAY be freely set and accepted. The version string
+MUST consist of printable US-ASCII characters.
-Thus, the version string could be, for example:
+Thus, the version strings could be, for example:
.in 6
+SILC-1.1-2.0.2
SILC-1.0-1.2
+SILC-1.1-1.0.VendorXYZ
+SILC-1.1-2.4.5 Vendor Limited
.in 3
If the sender has received earlier a private message from the receiver
it should have cached the Client ID from the SILC Packet Header.
+If server receives a private message packet which includes invalid
+destionation Client ID the server MUST send SILC_COMMAND_IDENTIFY
+command reply packet destined to the client with error status.
+
See [SILC2] for description of private message encryption and decryption
process.
[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.
70100 Kuopio
Finland
-EMail: priikone@silcnet.org
+EMail: priikone@iki.fi
This Internet-Draft expires XXX