JEP-0000: Protocol Switch

This document defines an XMPP extension for negotiating the change to a different network protocol on the same network socket.

JEP Information

Status: Proto
Type: Standards Track
Number: 0000
Version: 1.0
Last Updated: 2006-04-12
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: switch
Schema for feature: <http://jabber.org/protocol/switch/feature.xsd>
Schema for switch: <http://jabber.org/protocol/switch/switch.xsd>
Registry: <http://www.jabber.org/registrar/switch.html>
Wiki Page: <http://wiki.jabber.org/index.php/Protocol Switch (JEP-0000)>

Author Information

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

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

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 Jabber Software 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 JEP 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.

Conformance Terms

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

Table of Contents

1. Introduction

There are situations when it is absolutely useful to be able to morph an XMPP stream into a different protocol scheme. For instance when implementing user-friendly im:user@host addressing for several IM technologies. You can try XMPP by default, then switch to the other technology if XMPP wasn't the right guess. It allows XMPP to be used as default IM technology.

2. Use Case

The protocol flow is as follows:

Example 1. Receiving Entity Offers Protocol Switch Feature

<stream:features>
  <switch xmlns='http://jabber.org/protocol/switch'>
    <scheme>psyc</scheme>
  </switch>
</stream:features>
    

Note: The <switch/> element MUST contain at least one <scheme/> child element. Each <scheme/> element MUST contain XML character data that specifies the name of a protocol to switch to, and such scheme names SHOULD be registered as described in the Protocol Schemes Registry section of this document. The schemes SHOULD be provided in order of preference.

This document as of now only proposes the 'psyc' scheme with PSYC (Protocol for SYnchronous Conferencing) [1] being the only known applicant for this protocol switch function at the time of writing.

The initiating entity then MAY request the protocol switch by specifying one of the schemes advertised by the receiving entity:

Example 2. Initiating Entity Requests Protocol Switch

<switching xmlns='http://jabber.org/protocol/switch'>    
  <scheme>psyc</scheme>
</switching>
    

Note: If the initiating entity did not understand any of the advertised protocols to switch to, it SHOULD ignore the protocol switch option and proceed as if no switch schemes were advertised.

If the initiating entity requests a protocol scheme that is not supported by the receiving entity, the receiving entity MUST return an <unsupported-scheme/> error:

Example 3. Receiving Entity Reports That Scheme is Unsupported

<failure xmlns='http://jabber.org/protocol/switch'>
  <unsupported-scheme/>
</failure>
    

If the receiving entity finds the requested scheme unacceptable or unworkable for any other reason, it MUST return a <switch-failed/> error:

Example 4. Receiving Entity Reports That Negotiation of Protocol Switch Failed

<failure xmlns='http://jabber.org/protocol/switch'>
  <switch-failed/>
</failure>
    

Note: Failure of the negotiation SHOULD NOT be treated as an unrecoverable error and therefore SHOULD NOT result in a stream error. In particular, the initiating entity is free to retry the protocol switch negotiation if it fails.

If no error occurs, the receiving entity MUST inform the initiating entity that protocol switch has been successfully negotiated:

Example 5. Receiving Entity Acknowledges Negotiation of Protocol Switch

<switched xmlns='http://jabber.org/protocol/switch'/>
    

Both entities MUST now consider the previous XMPP stream to be null and void, just as with TLS negotiation and SASL negotiation (as specified in RFC 3920) and MUST begin communications according to the specifications of the negotiated protocol scheme and are thus beyond the scope of this document.

3. Business Rules

The following business rules apply:

• If stream protocol switch is negotiated, it SHOULD only take place on the TCP connection where the requesting entity connected to. The other direction should be shut down, if it was created at all.
• Negotiation of stream protocol switch may be completed before or after authentication via SASL (see RFC 3920 or Non-SASL Authentication [2]) and negotiation of TLS according to the needs and requirements of the involved protocol scheme and its application.

4. Implementation Notes

5. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [3].

6. Jabber Registrar Considerations

<scheme>
  <name>the XML character data of the scheme element</name>
  <desc>a natural-language description of the protocol scheme</desc>
  <doc>the document that specifies or registers the protocol to switch to</doc>
</scheme>
        

<scheme>
  <name>psyc</name>
  <desc>PSYC: Protocol for SYnchronous Conferencing</desc>
  <doc>http://www.psyc.eu</doc>
</scheme>
        

7. XML Schemas

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/features/switch'
    xmlns='http://jabber.org/features/switch'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      <!-- JEP-0000: http://www.jabber.org/jeps/jep-0000.html -->
      http://switch.psyced.org
    </xs:documentation>
  </xs:annotation>

  <xs:element name='switch'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='scheme' type='xs:NCName' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

</xs:schema>
      

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/switch'
    xmlns='http://jabber.org/protocol/switch'
    elementFormDefault='qualified'>

  <xs:import namespace='urn:ietf:params:xml:ns:xmpp-stanzas'/>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      <!-- JEP-0000: http://www.jabber.org/jeps/jep-0000.html -->
      http://switch.psyced.org
    </xs:documentation>
  </xs:annotation>

  <xs:element name='switching'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='scheme' type='xs:NCName' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='switched' type='empty'/>

  <xs:element name='failure'>
    <xs:complexType>
      <xs:choice>
        <xs:element name='switch-failed' type='empty'/>
        <xs:element name='unsupported-scheme' type='empty'/>
        <xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'>
          <xs:group ref='err:stanzaErrorGroup'/>
          <xs:element ref='err:text' minOccurs='0'/>
        </xs:sequence>
      </xs:choice>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
      

Notes

Revision History

END