XEP-proto-muc-bytestream: MUC Bytestreams

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://www.xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.

Document Information

Series: XEP
Number: proto-muc-bytestream
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: External extension
Version: 0.0.1
Last Updated: 2007-09-07
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0045
Supersedes: None
Superseded By: None
Short Name: NOT YET ASSIGNED

Author Information

Simon McVittie

Email: simon.mcvittie@collabora.co.uk
JabberID: simon.mcvittie@collabora.co.uk

Legal Notice

Discussion Venue

1. Introduction
2. Requirements
3. Use Cases
4. Security Considerations
5. IANA Considerations
6. XMPP Registrar Considerations
7. XML Schema
Notes
Revision History

1. Introduction

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).

2. Requirements

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.

3. Use Cases

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.

    
    <message from='chat@conf.example/someone' to='chat@conf.example'
      type='groupchat'>
      <data
        xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream"
        sid="some-stream-id'>base64base64...</data>
    </message>

    
    <message from='chat@conf.example/someone' to='chat@conf.example/otherguy'
      type='groupchat'>
      <data
        xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream'
        sid='some-stream-id'>base64base64...</data>
    </message>

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.

    
    <!--This example sends a message to all participants, but the process
    to send a message to one participant is the same -->

    <message from='chat@conf.example/someone' to='chat@conf.example'
        type='groupchat'>
      <data frag='first'
        xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream'
        sid='some-stream-id'>base64base64...</data>
    </message>

    <!-- 0 or more stanzas with frag='middle' - this example
      has one such stanza -->
    <message from='chat@conf.example/someone' to='chat@conf.example'
        type='groupchat'>
      <data frag='middle'
        xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream'
        sid='some-stream-id'>base64base64...</data>
    </message>

    <message from='chat@conf.example/someone' to='chat@conf.example'
        type='groupchat'>
      <data frag='last'
        xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream"
        sid="some-stream-id'>base64base64...</data>
    </message>

4. Security Considerations

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.

5. IANA Considerations

6. XMPP Registrar Considerations

7. XML Schema

    <xs:schema
      xmlns:xs='http://www.w3.org/2001/XMLSchema'
      targetNamespace='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream'
      xmlns='http://telepathy.freedesktop.org/xmpp/protocol/muc-bytestream'
      elementFormDefault='qualified'>

      <xs:element name='data'>
        <xs:complexType>
          <xs:simpleContent>
            <xs:extension base="xs:base64Binary">
              <xs:attribute name='sid' type='xs:string' use='required' />
              <xs:attribute name='frag' use='optional' default='complete'>
                <xs:restriction base='xs:NCName'>
                  <xs:enumeration value='first' />
                  <xs:enumeration value='middle' />
                  <xs:enumeration value='last' />
                  <xs:enumeration value='complete' />
                </xs:restriction>
              </xs:attribute>
            </xs:extension>
          </xs:simpleContent>
        </xs:complexType>
      </xs:element>
    </xs:schema>