This document describes a protocol for tunneling binary message streams through an XMPP MUC (XEP-0045). It's designed for use in Tubes but could be useful for other similar protocols.

The XML namespace defined here is http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream (NS_MUC_BYTESTREAM in Gabble source code).

D-Bus Tubes require a mechanism by which binary messages, possibly larger than the MUC service's maximum message size, can be transmitted through a MUC, preserving message boundaries. Multicasting messages to all participants, and sending unicast messages to a single participant, are both required.

The protocol used is intentionally similar to IBB (XEP-0047).

MUC Bytestream messages are multiplexed using a stream ID similar to that used in In-Band Bytestreams. As with In-Band Bytestreams, the stream ID SHOULD be randomly generated in a way that will avoid collisions, and any specification that references this one will need to describe how the stream ID can be associated with a higher-level construct (e.g. a Tube).

The uniqueness requirement for stream IDs is per-MUC, not per-participant, so collision avoidance must occur with the same scope.

Within a particular message stream, some messages can be broadcast to all participants in the MUC while some messages can be sent to a particular participant.

Messages which are too large for the MUC to relay them intact SHOULD be "fragmented", i.e. split into multiple stanzas.

To send messages which need to be fragmented, set the 'frag' attribute to "first" on the first part of the message, "middle" on any intermediate parts and "last" on the last part. Setting 'frag' to "complete", or omitting it, means the XMPP stanza is a complete message in the underlying message stream, i.e. it is simultaneously the first and last fragment.

When receiving messages, participants MUST buffer and reassemble fragmented messages independently for each (sender, 'sid') pair.

When a participant has started to send a fragmented message, it MUST send all the fragments of that message, finishing with one with 'frag' set to "last", before it starts to send any subsequent message with the same 'sid' attribute.

If a participant leaves the MUC, or signals via a higher-level protocol that it has left the MUC Bytestream stream with a particular 'sid', any buffered fragments from that sender representing an incomplete message SHOULD be discarded by recipients.

Senders can cause denial of service to recipients via memory exhaustion if they send very large fragmented messages. Recipients MUST impose a limit on the size of message they will reassemble; higher-level protocols that reference this one SHOULD recommend a suitable limit for that protocol.

None.

None.