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 is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.

Table of Contents

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.

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

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.

Example 1. Sending a short binary message to all participants

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

Example 2. Sending a short binary message to a single participant

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

Example 3. Sending a long binary message

    
    <!--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

None.

6. XMPP Registrar Considerations

None.

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>
  

Appendices

Appendix A: 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

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END