Author: Guillaume Desmottes
Description: Extension of XEP-0095 allowing to negotiate more than one bytestream to be used as a fallback.
Date: 2008-12-11

# XEP-si-multiple: Stream initiation multi-bytestreams extension

Extension of XEP-0095 allowing to negotiate more than one bytestream to be used as a fallback.

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: si-multiple
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Extension
Version: 0.0.1
Last Updated: 2008-12-11
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0095
Supersedes: None
Superseded By: None
Short Name: NOT YET ASSIGNED

## Author Information

### Guillaume Desmottes

Email: guillaume.desmottes@collabora.co.uk
JabberID: guillaume.desmottes@collabora.co.uk

## Legal Notices

### Copyright

### Permissions

### Disclaimer of Warranty

### Limitation of Liability

### IPR Conformance

## Discussion Venue

The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

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

## Table of Contents

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

## 1. Introduction

This document describes an extension of the Stream Initiation (SI) protocol. With current SI protocol, the receiver has to choose which bytestream method he wants to use for the data streaming. If he chooses an efficient method as SOCKS5 (XEP-0065) and this method fails because of network topology, the SI fails and data can't be transferred. The protocol described in this document aims to solve this problem by allowing users to fallback to another bytestream method if the first one failed.

## 2. Use Cases

When sending a SI request, the sender informs the receiver that he supports multi-bytestreams by adding the si-multiple node.

Example 1. Romeo sends a SI offer to Juliet

        <iq to='juliet@capulet.lit/Balcony' type='reply' id='H_1' from='romeo@montague.lit/Home'>
          <si xmlns='http://jabber.org/protocol/si' profile='http://telepathy.freedesktop.org/xmpp/tubes' id='alpha'>
            <feature xmlns='http://jabber.org/protocol/feature-neg'>
              <x xmlns='jabber:x:data' type='form'>
                <field var='stream-method' type='list-single'>
                  <option><value>http://jabber.org/protocol/bytestreams</value></option>
                  <option><value>http://jabber.org/protocol/ibb</value></option>
                </field>
              </x>
            </feature>
            <stream xmlns='http://telepathy.freedesktop.org/xmpp/tubes' tube='370459677'/>
            <si-multiple xmlns='http://telepathy.freedesktop.org/xmpp/si-multiple'/>
          </si>
        </iq>

If the receiver support multi-bytestreams as well, he sends a list of the methods supported instead of the normal SI reply. Bytestreams will be try by the sender in that order.

Example 2. Juliet replies to SI offer

        <iq to='juliet@capulet.lit/Balcony' type='set' id='H_1' from='romeo@montague.lit/Home'>
          <si xmlns='http://jabber.org/protocol/si'>
            <si-multiple xmlns='http://telepathy.freedesktop.org/xmpp/si-multiple>
              <value>http://jabber.org/protocol/bytestreams</value>
              <value>http://jabber.org/protocol/ibb</value>
            </si-multiple>
          </si>
        </iq>

At this point Romeo starts to initiate the bytestream using the first method (XEP-0065). If that fails, he'll try the second one (XEP-0047). Each bytestream is negotiated according the protocol described in its XEP. Once a bytestream has been sucessfully established, all the data are send using it and the other methods are not used.

## 3. Security Considerations

None.

## 4. IANA Considerations

None.

## 5. XMPP Registrar Considerations

None.

## 6. XML Schema

TODO

## Notes

## Revision History

#### Version 0.0.1 (2008-12-11)

First draft.

(cassidy)

END