A tube is a mechanism for arbitrary data transfer between
two or more IM users, used to allow applications on the users'
systems to communicate without having to establish network
connections themselves. Currently, two types of tube exist:
Tube channels can be requested for handles of type HANDLE_TYPE_CONTACT (for 1-1 communication) or of type HANDLE_TYPE_ROOM (to communicate with others in the room simultaneously).
As an exception to the usual handling of capabilities, connection managers
for protocols with capability discovery, such as XMPP, SHOULD advertise the
capability representing each Tube type that they support
(
To lower the barrier entry of new tube application, CM SHOULD accept to offer tubes of any
Each tube has a dictionary of arbitrary parameters. Parameters are commonly used to bootstrap legacy protocols where you can't negotiate parameters in-band. The allowable keys, types and values are defined by the service. Connection managers must support the value being a string (D-Bus type 's'), array of bytes (D-Bus type 'ay'), unsigned integer (D-Bus type 'u'), integer (D-Bus type 'i') and boolean (D-Bus type 'b').
When the tube is offered, the parameters are transmitted with the offer and appear as a property of the incoming tube for other participants.
Example of valid parameters for 'smb' Server Message Block over
TCP/IP (from DNS
SRV (RFC 2782) Service Types
http://www.dns-sd.org/ServiceTypes.html):
{'u': 'username', 'p': 'password', 'path': 'path'}
When requesting a channel with
When receiving an incoming tube, this property is immutable and so advertised in the
State of the tube in this channel.
When requesting a channel with