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 was autogenerated from the telepathy-gabble source tree and could be outdated, please check the git repository for an updated version. [Fri Jan 23, 2009]

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