XEP-0183: Jingle Telepathy Transport

NOTICE: This document is Humorous. It MAY provide amusement but SHOULD NOT be taken seriously.

Table of Contents

1. Introduction

Jingle [1] defines a framework for negotiating and managing out-of-band multimedia sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor media (session) types, leaving that up to separate specifications.

Typical peer-to-peer session types include voice chat (see Jingle RTP Sessions [2]) and video chat (see Jingle Video via RTP [3]). But Jingle can go farther. Indeed, why not support not only physical multimedia sessions (limited to the five physical senses) but also psychical multimedia sessions (which go beyond the basic physical senses to include advanced, extra-sensory perception)? The media (or medium) may be different, but the underlying principles are the same: fostering freedom of conversation by connecting people (e.g., through mind-reading and séances) and even applications such as accessing information from the future (e.g., in clairvoyance and precognition). Indeed, the ability to communicate with the spirit world will push Jabber/XMPP technologies into a new age of real-time communications (light years ahead of traditional IM and VoIP systems). Beyond Internet telephony, our innovations in Internet telepathy will give new meaning to the term "voice chat" as users are able to hear voices from the past, present, or future.

Unfortunately, these advanced session types cannot be supported using existing transport mechanisms such as Jingle ICE-UDP Transport Method [4], Jingle Raw UDP Transport Method [5], and Jingle IAX Transport Method [6]. Therefore, this document defines a new Jingle transport method for establishing and managing Extra-Sensory Perception (ESP) streams: the "telepathy" method.

2. Requirements

The Jingle telepathy transport method is designed to meet the following requirements:

1. Make it possible to establish and manage extra-sensory perception (ESP) streams between two XMPP entities.
2. Make it relatively easy to implement support in standard Jabber/XMPP clients.
3. Where communication with non-XMPP (indeed, non-material) entities is needed, push as much complexity as possible onto gateways between this world and the spirit world.

Note: Whether or not an ESP stream can be established depends on the user's native telepathic abilities as well as acquired telepathic skills such as grounding, centering, pinging, pulse-sending, broadcasting, scanning, probing, suggestion, and projection. [7] Your mileage may vary.

3. Protocol Description

<iq from='medium@example.com/seance' to='psychic@example.net/spiritworld' id='jingle1' type='set'>
  <jingle xmlns='http://jabber.org/protocol/jingle' 
          action='session-initiate' 
          initiator='medium@example.com/seance'
          sid='a73sjjvkla37jfea'>
    <description xmlns='urn:xmpp:example'/>
    <transport xmlns='http://jabber.org/protocol/jingle/transport/telepathy'>
      <candidate name='ihearvoices' generation='0' plane='9' pulse='80'
                 psi-sig='yellow happy bright open no-shields' 
                 sign='Pisces' time='present'/>
    </transport>
  </jingle>
</iq>
    

<iq type='result' from='psychic@example.net/spiritworld' to='medium@example.com/seance' id='jingle1'/>
    

<iq type='set' from='psychic@example.net/spiritworld' to='medium@example.com/seance' id='jingle2'>
  <jingle xmlns='http://jabber.org/protocol/jingle' 
          action='transport-accept' 
          initiator='medium@example.com/seance'
          sid='a73sjjvkla37jfea'>
    <transport xmlns='http://jabber.org/protocol/jingle/transport/telepathy'>
      <candidate name='ihearvoices'/>
    </transport>
  </jingle>
</iq>
    

<iq from='medium@example.com/seance' to='psychic@example.net/spiritworld' id='jingle2' type='result'/>
    

4. Deployment Notes

This specification applies exclusively to Jabber/XMPP clients and places no additional requirements on Jabber/XMPP servers. However, service administrators may wish to deploy a gateway to the spirit world in order to ease the channel negotiation process. How to develop such gateways is an inexact science (but it is a science!) and therefore is outside the scope of this document.

5. Security Considerations

To the author's knowledge, no channel encryption technologies exist for direct spiritual connections. Although this vulnerability can be mitigated through speaking in tongues and the use of various alternative languages such as Runic and Mumbo-Jumbo, the result is only security through obscurity, not channel encryption as those familiar with the merely material world understand it. If only benighted materialist scientists and technologists would recognize the validity of psychical experience and extra-sensory perception, progress in applying encryption principles to psychical channeling and the exchange of pure spiritual energy would rapidly ensue.

6. IANA Considerations

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

7. XMPP Registrar Considerations

<transport>
  <name>telepathy</name>
  <desc>
    A method for the negotiation of Extra-Sensory Perception (ESP) streams. 
  </desc>
  <doc>XEP-0183</doc>
</transport>
    

8. XML Schemas

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

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

  <xs:element name='transport'>
    <xs:complexType>
      <xs:choice>
        <xs:sequence>
          <xs:element ref='candidate' minOccurs='0' maxOccurs='1'/>
        </xs:sequence>
      </xs:choice>
    </xs:complexType>
  </xs:element>

  <xs:element name='candidate'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='generation' type='xs:unsignedByte' use='required'/>
          <xs:attribute name='name' type='xs:string' use='required'/>
          <xs:attribute name='plane' type='xs:positiveInteger' use='optional'/>
          <xs:attribute name='pulse' type='xs:positiveInteger' use='optional'/>
          <xs:attribute name='psi-sig' type='xs:string' use='optional'/>
          <xs:attribute name='sign' use='optional'>
            <xs:simpleType>
              <xs:restriction base='xs:NCName'>
                <xs:enumeration value='Aquarius'/>
                <xs:enumeration value='Aries'/>
                <xs:enumeration value='Cancer'/>
                <xs:enumeration value='Capricorn'/>
                <xs:enumeration value='Gemini'/>
                <xs:enumeration value='Leo'/>
                <xs:enumeration value='Libra'/>
                <xs:enumeration value='Pisces'/>
                <xs:enumeration value='Sagittarius'/>
                <xs:enumeration value='Scorpio'/>
                <xs:enumeration value='Taurus'/>
                <xs:enumeration value='Virgo'/>
              </xs:restriction>
            </xs:simpleType>
          </xs:attribute>
          <xs:attribute name='time' use='optional'>
            <xs:simpleType>
              <xs:restriction base='xs:NCName'>
                <xs:enumeration value='future'/>
                <xs:enumeration value='past'/>
                <xs:enumeration value='present'/>
              </xs:restriction>
            </xs:simpleType>
          </xs:attribute>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

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

</xs:schema>
    

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

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

  <xs:element name='message' type='xs:string'/>

</xs:schema>
    

Appendices

Appendix A: Document Information

Series: XEP
Number: 0183
Publisher: XMPP Standards Foundation
Status: Active
Type: Humorous
Version: 1.0
Last Updated: 2006-04-01
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0166
Supersedes: None
Superseded By: None
Short Name: telepathy
Source Control: HTML  RSS

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