Leaving the MUC also implicitly implies leaving all tubes.

If Juliet's web browser opens multiple parallel connections to her XMPP implementation, the implementation will open multiple parallel SI streams as shown above, and Romeo's XMPP implementation will open multiple parallel connections to his web server. This MUST be supported by implementations.

The D-Bus unique names used in the MUC SHOULD be ":2." followed by the MUC nick (i.e. the resource part of the MUC JID) processed with the following algorithm:

• Let utf8nick be the MUC nick encoded using UTF-8
• If utf8nick has 186 octets or fewer, encode it using Base64; otherwise encode a string consisting of the first 169 octets of utf8nick, followed by the 20 octets of the SHA-1 of utf8nick (note that this is the whole of the raw binary SHA-1, and not the first half of the SHA-1 written in hexadecimal).
• Remove all whitespace
• Replace "+" with "_", "/" with "-" and "=" with "A"

This produces collision-free unique names of length no more than 251 octets (4/3 * 186 + 3) for nicknames no longer than 186 UTF-8 octets (replacing "=" with "A" is harmless here because XMPP resources cannot contain U+0000).

For longer nicknames it makes collisions highly unlikely, and produces 255-octet unique names (4/3 * 189 + 3), which still fit into D-Bus' 255-octet limit.

The choice of 186 and 169 for the magic numbers ensures that these long nicknames can only have unique-name collisions with other long nicknames, and that the Base64 encoding step when applied to long nicknames does not leave any trailing "=" characters.

Implementations MUST NOT use unique names that start with ":2." but are not formed according to the above rules, and SHOULD treat tube elements containing such a dbus-name as if they were invalid.

For backwards compatibility with earlier implementations, the dbus-name MAY also be ":1." followed by an arbitrary unique string of up to 252 characters chosen from A-Z, a-z, 0-9, "-" or "_".

The Tubes SI profile is indicated by the profile string &NS_TUBES;. A Tubes SI IQ can be classified as follows:

• If the IQ contains a <tube> element with the namespace &NS_TUBES;, then the IQ represents a new tube being offered.
• If the IQ contains a <stream> element with the namespace &NS_TUBES;, then the IQ represents a new connection to an existing stream tube in a 1-1 Tubes channel.
• If the IQ contains a <muc-stream> element with the namespace &NS_TUBES;, then the IQ represents a new connection to an existing stream tube in a MUC Tubes channel - this message type is invalid and must be rejected unless received via a MUC.
• Otherwise, the SI is invalid and MUST be rejected.

The allowed parameter types are:

• "str": A Unicode string containing no zero bytes '\0'. In this implementation it cannot contain any other character forbidden by XML either. The <parameter> character content is the string itself. The corresponding D-Bus signature is 's'.
• "bytes": An array of bytes, represented in Base64. The corresponding D-Bus signature is 'ay'.
• "uint": An unsigned integer representable in 32 bits. The corresponding D-Bus signature is 'u' or 'q' on input, 'u' on output, and the element's character content is an ASCII unsigned decimal integer.
• "int": A signed integer representable in 32 bits using two's complement. The corresponding D-Bus signature is 'i' or 'h' on input, 'i' on output, and the element's character content is an ASCII decimal integer, possibly starting with '-'.
• "bool": A boolean value represented as one of the strings "0" or "1", representing False and True respectively. The corresponding D-Bus signature is 'b'.

FIXME: how big do we want to allow a message to be? In the D-Bus specification the limit is 2**27 bytes, in the default dbus-daemon configuration (as used on the system bus) it's 32M.

FIXME: limit how many messages are queued up somehow (the system bus limits it to 127M in total)