From 2e69a362695ca008ef9b0447b46524b854907ad3 Mon Sep 17 00:00:00 2001 From: "Matthew A. Miller" Date: Thu, 2 Oct 2014 11:44:17 -0600 Subject: [PATCH] XEP-0353 v0.1: Initial published version approved by XMPP Council --- inbox/jingle-message.xml => xep-0353.xml | 16 +++++++++++----- xep.ent | 7 ++++--- 2 files changed, 15 insertions(+), 8 deletions(-) rename inbox/jingle-message.xml => xep-0353.xml (97%) diff --git a/inbox/jingle-message.xml b/xep-0353.xml similarity index 97% rename from inbox/jingle-message.xml rename to xep-0353.xml index 2574e0b3..ecae4f25 100644 --- a/inbox/jingle-message.xml +++ b/xep-0353.xml @@ -9,8 +9,8 @@ Jingle Message Initiation 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. &LEGALNOTICE; - xxxx - ProtoXEP + 0353 + Experimental Standards Track Standards Council @@ -22,6 +22,12 @@ jingle-message &fippo; &stpeter; + + 0.1 + 2014-10-02 + XEP Editor (mam) +

Initial published version approved by the XMPP Council.

 + 0.0.2 2014-08-28 @@ -36,7 +42,7 @@ -

Because &xep0166; uses &IQ; stanzas for all interactions between the parties to a session, when sending an invitation the initiator needs to either pick one of the responder's resources (e.g., based on &xep0115; 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 &xep0276; 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.

+

Because &xep0166; uses &IQ; stanzas for all interactions between the parties to a session, when sending an invitation the initiator needs to either pick one of the responder's resources (e.g., based on &xep0115; 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 &xep0276; 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.

 @@ -91,7 +97,7 @@ - @@ -145,7 +151,7 @@ - diff --git a/xep.ent b/xep.ent index b304fb64..705c995e 100644 --- a/xep.ent +++ b/xep.ent @@ -1,9 +1,9 @@