Software: Apache/2.2.16 (Debian). PHP/5.3.3-7+squeeze19 

uname -a: Linux mail.tri-specialutilitydistrict.com 2.6.32-5-amd64 #1 SMP Tue May 13 16:34:35 UTC
2014 x86_64 

uid=33(www-data) gid=33(www-data) groups=33(www-data) 

Safe-mode: OFF (not secure)

/usr/share/doc/telepathy-gabble/   drwxr-xr-x
Free 129.99 GB of 142.11 GB (91.47%)
                            Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    

Viewing file:     si-multiple.html (10.42 KB)      -rw-r--r--

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

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

Appendices

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

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