XEP-0353: Jingle Message Initiation

Abstract
This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder's online resources or choosing a particular online resource.
Authors
  • Philipp Hancke
  • Peter Saint-Andre
  • Thilo Molitor
Copyright
© 1999 – 2021 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

Experimental

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.
Type
Standards Track
Version
0.5.0 (2022-01-05)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Stable
  4. Final

1. Introduction

Jingle (XEP-0166) [4] uses <iq/> stanzas for all interactions between the parties to a jingle session. When sending an invitation the initiator needs to either pick one of the responder's resources (e.g., based on Entity Capabilities (XEP-0115) [5] information) or send the invitation to all of the responder's resources that support Jingle. The first method is prone to error (e.g., in cases where more than one resource supports Jingle) and the second method requires sending a separate invitation to each resource. Neither of these is ideal. Although Presence Decloaking (XEP-0276) [6] proposed a way to overcome the problem, it too has issues (e.g., dependency on a presence service and the need to reveal all supported XMPP features) and in any case has not been widely implemented.

This document proposes an alternative solution: exchanging a <message/> stanza before sending the Jingle invitation in an <iq/> stanza. (Indeed, in the early discussions leading up to the Jingle protocol the authors considered using <message/> stanzas instead of <iq/> stanzas, but chose the latter for their deterministic handling semantics.) This method effectively results in a kind of decloaking for Jingle purposes.

Message Carbons (XEP-0280) [1] and Message Archive Management (XEP-0313) [2] (including Message Processing Hints (XEP-0334) [3]) make sure all devices (offline or not) know about the jingle session, its start timestamp and even its end timestamp and the state in between.

2. Requirements

This protocol was designed with the following requirements in mind:

3. Use Cases

All <message/> stanzas exchanged by this protocol MUST be of type="chat" and contain Message Processing Hints (XEP-0334) [3] <store/> hints.

3.1 Indicating Intent to Start a Session

In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a <message/> stanza containing a <propose/> element qualified by the 'urn:xmpp:jingle-message:1' namespace. The <propose/> element MUST possess an 'id' attribute being a globally unique identifier. It therefore is RECOMMENDED to use UUIDv4. This id will also be used for the session invitation of Jingle (XEP-0166) [4] later on. The <propose/> element MUST contain one <description/> element for each media type associated with the intended session.

Example 1. Initiator Sends Intent Message
<message from='romeo@montague.example/orchard'
         to='juliet@capulet.example'
         type='chat'>
  <propose xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
    <description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/>
  </propose>
  <store xmlns="urn:xmpp:hints"/>
</message>

The server of the responder (e.g., Juliet) distributes this message stanza to all of Juliet's available resources (and to push resources as appropriate) thanks to Message Carbons (XEP-0280) [1] and Message Archive Management (XEP-0313) [2]. Those devices might start ringing as a result.

Consistent with the recommendation for one-to-one chat sessions in Section 5.1 of RFC 6121 [7], the initiator SHOULD also send directed presence to the responder if the two entities do not already share presence information; including Entity Capabilities (XEP-0115) information in this directed presence stanza enables the responder to know the availability of the initiator (e.g., in case the message is actually delivered quite a bit later because it is saved to Message Archive Management (XEP-0313) [2] storage) and also to know the XMPP features supported by the initiator.

Example 2. Initiator Sends Directed Presence
<presence to='romeo@montague.example/orchard'
          from='juliet@capulet.example'>
  <c xmlns='http://jabber.org/protocol/caps'
     hash='sha-1'
     node='http://psi-im.org'
     ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/>
</presence>

3.2 Disavowing Intent to Start a Session

It can happen that the initiator might want to disavow intent to send a session invitation (e.g., because the initiator has accepted another session). The initiator can do so by sending a message stanza containing a <retract/> element specifying the same session ID.

The <retract/> element MUST contain a <reason/> element as defined in Jingle (XEP-0166) [4] section 7.4. This SHOULD use a condition of <cancel/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).

Example 3. Initiator Sends Stop Message
<message from='romeo@montague.example/orchard'
         to='juliet@capulet.example'
         type='chat'>
  <retract xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
    <reason xmlns="urn:xmpp:jingle:1">
      <cancel/>
      <text>Retracted</text>
    </reason>
  </retract>
  <store xmlns="urn:xmpp:hints"/>
</message>

In conjunction with Message Archive Management (XEP-0313) [2] upon ending the catchup phase the responder SHOULD consider all sessions for which it received a <propose/> but no <retract/> or <finish/> message to be still active and allow the user to accept the intent to start a session.

3.3 Accepting Intent to Start a Session

Upon receiving the intent message, the responder's various devices will "ring" and the responder will answer the call on a particular device. Here we assume that since this is an audio-only call, Juliet chooses to take the call on the device associated with her "phone" resource.

Her "phone" resource informs all of her resources and all of the initiator's resources about accepting the call by sending a message to the bare JID of the initiator containing an <accept/> element specifying the session ID of the original <propose/> message.

Example 4. One of Responder's Resources Accepts the Call
<message from='juliet@capulet.example/phone'
         to='romeo@montague.example'
         type='chat'>
  <accept xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'/>
  <store xmlns="urn:xmpp:hints"/>
</message>

Juliet's server broadcasts this accept message to all of her resources (as described in Message Carbons (XEP-0280) [1]), which stop ringing, and to all of Romeo's resources (as described in RFC 6121 [7]). Romeo's resources that did not send the <propose/> can use this <message/> stanza to update their UI or choose to ignore this <message/> stanza altogether.

Next, the device from which Juliet accepted the call sends directed presence to Romeo for the reasons described above.

Example 5. Responder Sends Directed Presence
<presence from='juliet@capulet.example/phone'
          to='romeo@montague.example/orchard'>
  <c xmlns='http://jabber.org/protocol/caps'
     hash='sha-1'
     node='http://code.google.com/p/exodus'
     ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
</presence>

3.4 Rejecting Intent to Start a Session

Instead of accepting the call, the responder might want to decline the call and tell all of her devices to stop ringing (e.g., perhaps because Romeo is getting to be a bit of a nuisance). She does this by rejecting the call on one of her devices and having that device tell all of the other devices to stop ringing by sending a <message/> stanza containing a <reject/> element specifying the session ID of the original <propose/> message to the bare JID of Romeo.

The <reject/> element MUST contain a <reason/> element as defined in Jingle (XEP-0166) [4] section 7.4. The <reason/> element SHOULD use a condition of <busy/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).

In Tie-Breaking scenarios it MUST also contain a <tie-break/> element as defined in Tie Breaking.

Example 6. One of Responder's Resources Rejects the Call
<message from='juliet@capulet.example/phone'
         to='romeo@montague.example'
         type='chat'>
  <reject xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
    <reason xmlns="urn:xmpp:jingle:1">
      <busy/>
      <text>Busy</text>
    </reason>
  </reject>
  <store xmlns="urn:xmpp:hints"/>
</message>

3.5 Initiating the Jingle Session

Now Romeo actually initiates the session (segue to Jingle itself).

Example 7. Initiation
<iq from='romeo@montague.example/orchard'
    id='ih28sx61'
    to='juliet@capulet.example/phone'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle:1'
          action='session-initiate'
          initiator='romeo@montague.example/orchard'
          sid='a73sjjvkla37jfea'>
    <content creator='initiator' name='voice'>
      <description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
        <payload-type id='96' name='speex' clockrate='16000'/>
        <payload-type id='97' name='speex' clockrate='8000'/>
        <payload-type id='18' name='G729'/>
        <payload-type id='0' name='PCMU'/>
        <payload-type id='103' name='L16' clockrate='16000' channels='2'/>
        <payload-type id='98' name='x-ISAC' clockrate='8000'/>
      </description>
      <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
                 pwd='asd88fgpdd777uzjYhagZg'
                 ufrag='8hhy'>
        <candidate component='1'
                   foundation='1'
                   generation='0'
                   id='el0747fg11'
                   ip='10.0.1.1'
                   network='1'
                   port='8998'
                   priority='2130706431'
                   protocol='udp'
                   type='host'/>
        <candidate component='1'
                   foundation='2'
                   generation='0'
                   id='y3s2b30v3r'
                   ip='192.0.2.3'
                   network='1'
                   port='45664'
                   priority='1694498815'
                   protocol='udp'
                   rel-addr='10.0.1.1'
                   rel-port='8998'
                   type='srflx'/>
      </transport>
    </content>
  </jingle>
</iq>

3.6 Finishing a Started Session

This protocol in conjunction with Message Carbons (XEP-0280) [1] and Message Archive Management (XEP-0313) [2] allows all devices of both involved parties to get synchronized about session start, rejection etc. To synchronize the ending of the session, both parties MUST send a message stanza containing a <finish/> element specifying the same session ID as in Accept to the bare jid of the other party.

Letting both involved parties send the <finish/> element makes sure we have the correct state in MAM archives etc. even if one client suddenly looses connectivity/power. It even makes possible for a client to determine if the call is still deemed "running" by the other party if it manages to recover from connectivity loss — before the other party runs into a timeout and sends a <finish/> — to recover the session or formally terminate the call (by ending the Jingle session and sending a <finish/> message itself). See Tie Breaking for more infos on this and similar scenarios.

The <finish/> element MUST contain a <reason/> element as defined in Jingle (XEP-0166) [4] section 7.4. This SHOULD use a condition of <success/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).

Example 8. Initiator Sends Finish Message
<message from='romeo@montague.example/orchard'
         to='juliet@capulet.example'
         type='chat'>
  <finish xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
    <reason xmlns="urn:xmpp:jingle:1">
      <success/>
      <text>Success</text>
    </reason>
  </finish
  <store xmlns="urn:xmpp:hints"/>
</message>
Example 9. Responder Sends Finish Message
<message from='juliet@capulet.example/phone'
         to='romeo@montague.example'
         type='chat'>
  <finish xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
    <reason xmlns="urn:xmpp:jingle:1">
      <success/>
      <text>Success</text>
    </reason>
  </finish>
  <store xmlns="urn:xmpp:hints"/>
</message>

4. Tie Breaking

It is possible that a <propose/> message can be sent at the same time by both parties or a new session started while one is already running. Implementations of this specification MUST implement the following solutions to solve this. (This is loosely based upon section 7.2.16 of Jingle (XEP-0166) [4].)

4.1 No existing session

In this case (e.g. no party answered the <propose/> message yet) the lower of the two session IDs MUST overrule the other action, where by "lower" is meant the session ID that is sorted first using "i;octet" collation as specified in Section 9.3 of RFC 4790 [8] (in the unlikely event that the random session IDs are the same, the action sent by the lower of the JabberIDs MUST overrule the other action). The party that receives the <propose/> action with the lower of the two session IDs MUST respond with an <accept/> or <reject/> mesage like it would normally do for a <propose/> message, and the party that receives the <propose/> action with the higher of the two session IDs MUST return a <reject/> message to the other party with a <tie-break/> child element alongside of a <reason/> element carrying the condition <expired/>.

Example 10. Tie break in propose state
<!-- lower session ID -->
<message from='romeo@montague.example/orchard'
         to='juliet@capulet.example'
         type='chat'>
  <propose xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
    <description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/>
  </propose>
  <store xmlns="urn:xmpp:hints"/>
</message>

<!-- higher session ID -->
<message from='juliet@capulet.example/phone'
         to='romeo@montague.example'
         type='chat'>
  <propose xmlns='urn:xmpp:jingle-message:1' id='b73sjjvkla37jfea'>
    <description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/>
  </propose>
  <store xmlns="urn:xmpp:hints"/>
</message>

<!-- Romeo received the higher ID and rejects the call -->
<message from='romeo@montague.example/orchard'
         to='juliet@capulet.example'
         type='chat'>
  <reject xmlns='urn:xmpp:jingle-message:1' id='b73sjjvkla37jfea'>
    <reason xmlns="urn:xmpp:jingle:1">
      <expired/>
      <text>Tie-Break</text>
    </reason>
    <tie-break/>
  </reject>
  <store xmlns="urn:xmpp:hints"/>
</message>

<!-- Juliet received the lower ID and accepts the call -->
<message from='juliet@capulet.example/phone'
         to='romeo@montague.example'
         type='chat'>
  <accept xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'/>
  <store xmlns="urn:xmpp:hints"/>
</message>

4.2 Existing session

If (from the perspective of the responder of the new session) there is already a session to the bare-jid of the initiator active (e.g. call already accepted but no <finish/> element received by the responder so far), the old session MUST be deemed an orphan and terminated by the responder of the new session in favor of the new one. The responder MUST transparently accept the new session and finish the old one, because it can be assumed that this new session is a transparent continuation of the old one.

She does so by first accepting the new session (sending an <accept/> message like she would do normally) and then sending a <finish/> message including a child element whose to-attribute refers to the old Jingle session id and including a <reason/> condition of <expired/>.

That makes it possible for the initiator of the new session to transparently switch devices (e.g. migrate the call to a new device) or resume an alreay running session after a sudden connectivity/power loss.

Example 11. Tie break in accept state
<!-- old session gets proposed... -->
<message from='romeo@montague.example/orchard'
         to='juliet@capulet.example'
         type='chat'>
  <propose xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
    <description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/>
  </propose>
  <store xmlns="urn:xmpp:hints"/>
</message>

<!-- ...and accepted -->
<message from='juliet@capulet.example/phone'
         to='romeo@montague.example'
         type='chat'>
  <accept xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'/>
  <store xmlns="urn:xmpp:hints"/>
</message>

<!-- ...some time passes... -->

<!-- new session (device switch) -->
<message from='juliet@capulet.example/tablet'
         to='romeo@montague.example'
         type='chat'>
  <propose xmlns='urn:xmpp:jingle-message:1' id='x64sjjvkla37baka'>
    <description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'/>
  </propose>
  <store xmlns="urn:xmpp:hints"/>
</message>

<!-- Romeo accepts the call because it is assumed to be a continuation of the old session with id 'a73sjjvkla37jfea'... -->
<message from='romeo@montague.example/orchard'
         to='juliet@capulet.example'
         type='chat'>
  <accept xmlns='urn:xmpp:jingle-message:1' id='x64sjjvkla37baka'/>
  <store xmlns="urn:xmpp:hints"/>
</message>

<!-- ...and finishes the old session with id 'a73sjjvkla37jfea' directly afterwards using reason <expired/> -->
<!-- and including a <migrated/> element pointing to the new session id 'x64sjjvkla37baka' -->
<message from='romeo@montague.example/orchard'
         to='juliet@capulet.example'
         type='chat'>
  <finish xmlns='urn:xmpp:jingle-message:1' id='a73sjjvkla37jfea'>
    <reason xmlns="urn:xmpp:jingle:1">
      <expired/>
      <text>Session migrated</text>
    </reason>
    <migrated to='x64sjjvkla37baka'/>
  </finish>
  <store xmlns="urn:xmpp:hints"/>
</message>

<!-- ...some more time passes... -->

<!-- the new session is termianted normally by Romeo... -->
<message from='romeo@montague.example/orchard'
         to='juliet@capulet.example'
         type='chat'>
  <finish xmlns='urn:xmpp:jingle-message:1' id='x64sjjvkla37baka'/>
  <store xmlns="urn:xmpp:hints"/>
</message>

<!-- and Juliet... -->
<message from='juliet@capulet.example/tablet'
         to='romeo@montague.example'
         type='chat'>
  <finish xmlns='urn:xmpp:jingle-message:1' id='x64sjjvkla37baka'/>
  <store xmlns="urn:xmpp:hints"/>
</message>

5. Business Rules

Participants MUST use Message Carbons (XEP-0280) [1] and Message Archive Management (XEP-0313) [2] to make sure all devices of initiator and responder receive all messages exchanged by this protocol. Without Message Carbons (XEP-0280) [1] implementations would need to send copies of outgoing messages to their own bare jid, to inform their own devices about an event (like it was done with the <accept/> message in the old urn:xmpp:jingle:jingle-message:0 specification).

In a Message Archive Management (XEP-0313) [2] (or Stream Management (XEP-0198) [9]) catchup scenario client developers MAY choose to not show an "incoming call" UI upon receiving a <propose/> message because they could receive another message for the same Jingle session id later in the catchup process invalidating the <propose/> received before. Showing the "incoming call" UI as soon as receiving an <accept/> might comprise bad UX.

In the rare case of missing <finish/> elements from both initiator and responder, sessions SHOULD be considered terminated after an appropriate timeframe (for example 24 hours) and indicated so in the UI.

All 'id' attributes MUST be globally unique to make sure they do not collide, and therefore it is RECOMMENDED to use UUIDv4.

6. Security Considerations

Because exchanging messages with other entities is effectively is a presence leak, an XMPP client that implements the receiving side of this specification MUST disable sending of accept messages by default and MUST enable the feature only as a result of explicit user confirmation. Such confirmation can be provided per request, by automatically allowing requests received from Jingle initiators in the responder's contact list, or through some other suitable means as long as sending accept messages does not occur by default.

Because sending of reasons other than the default ones (e.g. <cancel/> for <retract/>, <busy/> or <expired/> for <reject/> and <success/> or <expired/> for <finish/>) may leak privacy related information the user does not want to leak, sending of those non-default reasons should be carefully considered by client developers.

7. Acknowledgements

Thanks to Lance Stout, Holger Weiß and Daniel Gultsch for their feedback.

8. IANA Considerations

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

9. XMPP Registrar Considerations

9.1 Protocol Namespaces

This specification defines the following XML namespace:

The XMPP Registrar [11] includes the foregoing namespace to the registry located at <https://xmpp.org/registrar/namespaces.html>, as described in Section 4 of XMPP Registrar Function (XEP-0053) [12].

9.2 Protocol Versioning

If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

10. XML Schema

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

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    xmlns:xml='http://www.w3.org/XML/1998/namespace'
    targetNamespace='urn:xmpp:jingle-message:1'
    xmlns='urn:xmpp:jingle-message:1'
    elementFormDefault='qualified'>

  <xs:element name='propose'>
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace='##other' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:attribute name='id' type='xs:string' use='required'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='accept'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='id' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>
  
  <xs:element name='finish'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='reason' type='reasonElementType' minOccurs='1' maxOccurs='1'/>
        <xs:element name='migrated' type='migratedElementType' minOccurs='0' maxOccurs='1'/>
      </xs:sequence>
      <xs:attribute name='id' type='xs:string' use='required'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='reject'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='reason' type='reasonElementType' minOccurs='1' maxOccurs='1'/>
        <xs:element name='tie-break' type='empty' minOccurs='0' maxOccurs='1'>
      </xs:sequence>
      <xs:attribute name='id' type='xs:string' use='required'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='retract'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='reason' type='reasonElementType' minOccurs='1' maxOccurs='1'/>
      </xs:sequence>
      <xs:attribute name='id' type='xs:string' use='required'/>
    </xs:complexType>
  </xs:element>

  <xs:complexType name='migratedElementType'>
    <xs:simpleContent>
      <xs:extension base='empty'>
        <xs:attribute name='to' type='xs:string' use='required'/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:complexType name='reasonElementType'>
    <xs:sequence>
      <xs:choice>
        <xs:element name='alternative-session' 
                    type='alternativeSessionElementType'/>
        <xs:element name='busy' type='empty'/>
        <xs:element name='cancel' type='empty'/>
        <xs:element name='connectivity-error' type='empty'/>
        <xs:element name='decline' type='empty'/>
        <xs:element name='expired' type='empty'/>
        <xs:element name='failed-application' type='empty'/>
        <xs:element name='failed-transport' type='empty'/>
        <xs:element name='general-error' type='empty'/>
        <xs:element name='gone' type='empty'/>
        <xs:element name='incompatible-parameters' type='empty'/>
        <xs:element name='media-error' type='empty'/>
        <xs:element name='security-error' type='empty'/>
        <xs:element name='success' type='empty'/>
        <xs:element name='timeout' type='empty'/>
        <xs:element name='unsupported-applications' type='empty'/>
        <xs:element name='unsupported-transports' type='empty'/>
      </xs:choice>
      <xs:element name='text' type='xs:string' minOccurs='0' maxOccurs='1'/>
      <xs:any namespace='##other' minOccurs='0' maxOccurs='1'/>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

Appendices

Appendix A: Document Information

Series
XEP
Number
0353
Publisher
XMPP Standards Foundation
Status
Experimental
Type
Standards Track
Version
0.5.0
Last Updated
2022-01-05
Approving Body
XMPP Council
Dependencies
XEP-0166, XEP-0280, XEP-0313, XEP-0334
Supersedes
None
Superseded By
None
Short Name
jingle-message
Source Control
HTML

This document in other formats: XML  PDF

Appendix B: Author Information

Philipp Hancke
Email
fippo@andyet.com
JabberID
fippo@goodadvice.pages.de
Peter Saint-Andre
Email
xsf@stpeter.im
JabberID
peter@jabber.org
URI
http://stpeter.im/
Thilo Molitor
Email
thilo+xmpp@eightysoft.de
JabberID
thilo.molitor@juforum.de

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) 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 <https://xmpp.org/community/> 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

1. XEP-0280: Message Carbons <https://xmpp.org/extensions/xep-0280.html>.

2. XEP-0313: Message Archive Management <https://xmpp.org/extensions/xep-0313.html>.

3. XEP-0334: Message Processing Hints <https://xmpp.org/extensions/xep-0334.html>.

4. XEP-0166: Jingle <https://xmpp.org/extensions/xep-0166.html>.

5. XEP-0115: Entity Capabilities <https://xmpp.org/extensions/xep-0115.html>.

6. XEP-0276: Presence Decloaking <https://xmpp.org/extensions/xep-0276.html>.

7. RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>.

8. RFC 4790: Internet Application Protocol Collation Registry <http://tools.ietf.org/html/rfc4790>.

9. XEP-0198: Stream Management <https://xmpp.org/extensions/xep-0198.html>.

10. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

11. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.

12. XEP-0053: XMPP Registrar Function <https://xmpp.org/extensions/xep-0053.html>.

Appendix H: Revision History

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

  1. Version 0.5.0 (2022-01-05)
    Recommend usage of UUID v4 for id attributes.
    tm
  2. Version 0.4.0 (2021-11-27)
    tm
  3. Version 0.3.1 (2021-03-04)

    Cross-document editorial adjustments for inclusive language.

    mw
  4. Version 0.3 (2017-09-11)
    Defer due to lack of activity.
    XEP Editor (jwi)
  5. Version 0.2.0 (2014-10-02)

    Add explicit reject by responding to sender with reject message.

    xd, XEP Editor: ssw
  6. Version 0.1 (2014-10-02)

    Initial published version approved by the XMPP Council.

    XEP Editor (mam)
  7. Version 0.0.2 (2014-08-28)

    Added explanatory text; defined more granular actions (propose, retract, accept, reject, proceed); mandated inclusion of description elements within the propose element, as in jingle-pub; defined schema.

    psa/ph
  8. Version 0.0.1 (2014-07-15)

    First draft.

    ph

Appendix I: Bib(La)TeX Entry

@report{hancke2014jingle-message,
  title = {Jingle Message Initiation},
  author = {Hancke, Philipp and Saint-Andre, Peter and Molitor, Thilo},
  type = {XEP},
  number = {0353},
  version = {0.5.0},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0353.html},
  date = {2014-07-15/2022-01-05},
}

END