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.

Only stream tubes use a message stanza to be closed. D-Bus tubes are closed implicitly when the underlying bytestream is closed and thus do not need an explicit message stanza.

Leaving the link-local MUC (a leave or split event from rMulticast) also implicitly implies leaving all tubes.

The tube feature is advertised with XEP-0115 Entity Capabilities using this string:

We want to know which tube the contacts can handle. There is two different kind of tube capabilities:

• Can my contact receive a tube offer of a specific service?
• Can my contact offer a tube of a specific service?

Only the first kind is considered. The second is out of scope of this specification. Each specific service is advertised with XEP-0115 Entity Capabilities with this string:

where $type is the tube type (either "dbus" or "stream") and $service is the service name (e.g. "vnc" or "TicTacTube").

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 D-Bus unique names used in a link-local MUC SHOULD be ":2." followed by the _presence._tcp instance name (e.g. mercutio@mab) processed with the algorithm above.

Again, 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.

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'. This corresponds to xs:string in XML Schema Part 2.
• "bytes": An array of bytes, represented in Base64. The corresponding D-Bus signature is 'ay'. This corresponds to xs:base64Binary in XML Schema Part 2.
• "uint": An unsigned integer representable in 32 bits. The corresponding D-Bus signature is 'u' or 'q' on input, 'u' on output. The element's character content is an ASCII unsigned decimal integer. This corresponds to xs:unsignedInt in XML Schema Part 2.
• "int": A signed integer representable in 32 bits using two's complement. The corresponding D-Bus signature is 'i' or 'n' on input, 'i' on output, and the element's character content is an ASCII decimal integer, possibly starting with '-' or '+'. This corresponds to xs:int in XML Schema Part 2.
• "bool": A boolean value represented as one of the strings "false", "true", "0" or "1", as per xs:boolean in XML Schema Part 2. The corresponding D-Bus signature is 'b'. (Implementation note: early versions of Tubes in Gabble only accepted "0" or "1", so implementations that care about backwards compatibility SHOULD emit those representations).

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)