moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

JEP to XEP

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@49 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-04 17:48:32 +00:00
parent 60c37405ae
commit 0392f0dfcb
10 changed files with 139 additions and 139 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
xep-0170.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Recommended Order of Stream Feature Negotiation</title>
<abstract>This document specifies a recommended order for negotiation of XMPP stream features.</abstract>
@ -16,9 +16,9 @@
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0077</spec>
<spec>JEP-0079</spec>
<spec>JEP-0138</spec>
<spec>XEP-0077</spec>
<spec>XEP-0079</spec>
<spec>XEP-0138</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -46,7 +46,7 @@
<version>0.1</version>
<date>2006-01-11</date>
<initials>psa</initials>
<remark>Initial JEP version.</remark>
<remark>Initial version.</remark>
</revision>
<revision>
<version>0.0.1</version>
@ -70,7 +70,7 @@
<p>That order MUST be followed if no other stream features are negotiated.</p>
</section2>
<section2 topic='Stream Compression' anchor='c2s-compress'>
<p>&jep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
<p>&xep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
<ol>
<li>TLS</li>
<li>SASL</li>
@ -80,7 +80,7 @@
</ol>
</section2>
<section2 topic='In-Band Registration' anchor='c2s-register'>
<p>The &jep0077; protocol can be used to establish an account before logging in. That step would be completed before SASL because an entity cannot authenticate if it does not first create an account. Therefore the following order is RECOMMENDED:</p>
<p>The &xep0077; protocol can be used to establish an account before logging in. That step would be completed before SASL because an entity cannot authenticate if it does not first create an account. Therefore the following order is RECOMMENDED:</p>
<ol>
<li>TLS</li>
<li>In-band registration</li>
@ -99,7 +99,7 @@
</ol>
</section2>
<section2 topic='Non-SASL Authentication' anchor='c2s-iqauth'>
<p>The legacy &jep0078; protocol can be used by clients to log into older (pre-XMPP) servers. In essence the "jabber:iq:auth" protocol is an older way of doing what the XMPP RFCs specify in the SASL, resource binding, and IM session stream features. Therefore the following order is RECOMMENDED:</p>
<p>The legacy &xep0078; protocol can be used by clients to log into older (pre-XMPP) servers. In essence the "jabber:iq:auth" protocol is an older way of doing what the XMPP RFCs specify in the SASL, resource binding, and IM session stream features. Therefore the following order is RECOMMENDED:</p>
<ol>
<li>TLS</li>
<li>jabber:iq:auth</li>
@ -113,7 +113,7 @@
</ol>
</section2>
<section2 topic='Advanced Message Processing' anchor='c2s-amp'>
<p>Support for the &jep0079; protocol is advertised as a stream feature but its use is not negotiated; therefore no recommendation is needed.</p>
<p>Support for the &xep0079; protocol is advertised as a stream feature but its use is not negotiated; therefore no recommendation is needed.</p>
</section2>
</section1>
<section1 topic='Server-to-Server Recommendations' anchor='s2s'>
@ -134,7 +134,7 @@
</ol>
</section2>
<section2 topic='Stream Compression' anchor='s2s-compress'>
<p>&jep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation fo both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
<p>&xep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation fo both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
<ol>
<li>TLS</li>
<li>SASL</li>
@ -152,9 +152,9 @@
<p>The order of negotiated stream features has security implications and may be security-critical. In particular, TLS MUST be negotiated first.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<p>This JEP requires no interaction with the Jabber Registrar.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the XMPP Registrar.</p>
</section1>
</jep>
</xep>

26
xep-0171.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Language Translation</title>
<abstract>This JEP defines a protocol for providing language translation facilities over XMPP. It supports human, machine, client-based, and server-based translations.</abstract>
<abstract>This document defines an XMPP protocol extension for providing language translation facilities over XMPP. It supports human, machine, client-based, and server-based translations.</abstract>
&LEGALNOTICE;
<number>0171</number>
<status>Experimental</status>
@ -17,7 +17,7 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -52,13 +52,13 @@
<version>0.1</version>
<date>2006-01-24</date>
<initials>psa</initials>
<remark>Initial JEP version.</remark>
<remark>Initial version.</remark>
</revision>
<revision>
<version>0.0.4</version>
<date>2006-01-17</date>
<initials>psa</initials>
<remark>Converted to JEP format, cleaned up text, modified examples, changed pivotable and reviewed attributes to xs:boolean, corrected schema.</remark>
<remark>Converted to XML format, cleaned up text, modified examples, changed pivotable and reviewed attributes to xs:boolean, corrected schema.</remark>
</revision>
<revision>
<version>0.0.3</version>
@ -186,7 +186,7 @@
</section2>
<section2 topic='Discovering Translation Providers' anchor='disco'>
<section3 topic='Discovering Translation Providers On a Server' anchor='disco-items'>
<p>When connected to a server, a XMPP entity can locate translation providers by asking a server which translation providers are attached to the server; this MUST be done using &jep0030;. The server SHOULD return the availability of of translation providers and language pairings for which the user has rights to use.</p>
<p>When connected to a server, a XMPP entity can locate translation providers by asking a server which translation providers are attached to the server; this MUST be done using &xep0030;. The server SHOULD return the availability of of translation providers and language pairings for which the user has rights to use.</p>
<example caption='Entity sends discovery request to server'><![CDATA[
<iq type='get' id='disco1' to='shakespeare.lit'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
@ -369,14 +369,14 @@
<p>This possible weakness can be mitigated by not returning specifics to requesting entities and the responding entity MAY perform authorization checks in order to determine how to respond.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/langtrans' and 'http://jabber.org/protocol/langtrans#items' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Service Discovery Identities' anchor='registrar-identity'>
<p>The Jabber Registrar shall add a type of "translation" to the "automation" category in its registry of service discovery identities.</p>
<p>The XMPP Registrar shall add a type of "translation" to the "automation" category in its registry of service discovery identities.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -464,4 +464,4 @@
]]></code>
</section2>
</section1>
</jep>
</xep>

46
xep-0172.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>User Nickname</title>
<abstract>This document defines a protocol for communicating user nicknames.</abstract>
@ -21,7 +21,7 @@
<supersededby/>
<shortname>nick</shortname>
<schemaloc>
<url>http://jabber.org/protocol/nick/nick.xsd</url>
<url>http://www.xmpp.org/schemas/nick.xsd</url>
</schemaloc>
&stpeter;
&val;
@ -65,7 +65,7 @@
<version>0.4</version>
<date>2006-03-20</date>
<initials>psa</initials>
<remark><p>To reflect use of dedicated namespace, (1) changed JEP type from Informational to Standards Track and (2) updated Jabber Registrar Considerations.</p></remark>
<remark><p>To reflect use of dedicated namespace, (1) changed JEP type from Informational to Standards Track and (2) updated XMPP Registrar Considerations.</p></remark>
</revision>
<revision>
<version>0.3</version>
@ -77,7 +77,7 @@
<version>0.2</version>
<date>2006-03-08</date>
<initials>psa</initials>
<remark><p>Added wrapper element from JEP-0154.</p></remark>
<remark><p>Added wrapper element from XEP-0154.</p></remark>
</revision>
<revision>
<version>0.1</version>
@ -109,7 +109,7 @@
<ul>
<li>Users like them.</li>
<li>They are easier to remember than JIDs.</li>
<li>They can be used to help prevent mimicking of JIDs (see &jep0165;).</li>
<li>They can be used to help prevent mimicking of JIDs (see &xep0165;).</li>
</ul>
<p>This document defines best practices that enable IM users to advertise their preferred nicknames over Jabber/XMPP instant messaging networks.</p>
</section1>
@ -141,9 +141,9 @@
]]></example>
<p>A nickname of this form has the same semantic meaning as the following data fields:</p>
<ul>
<li>The "NICKNAME" field specified in &jep0054;.</li>
<li>The "nickname" field specified in &jep0154;.</li>
<li>The "nickname" field specified in &jep0077;.</li>
<li>The "NICKNAME" field specified in &xep0054;.</li>
<li>The "nickname" field specified in &xep0154;.</li>
<li>The "nickname" field specified in &xep0077;.</li>
<li>The "nick" field specified in &foaf;.</li>
<li>The "Alias" field specified in the <cite>Extensible Name and Address Language</cite> <note>See &lt;<link url='http://xml.coverpages.org/xnal.html'>http://xml.coverpages.org/xnal.html</link>&gt;.</note> developed by &OASIS;.</li>
</ul>
@ -162,7 +162,7 @@
<example caption='A Basic Subscription Request'><![CDATA[
<presence from='narrator@moby-dick.lit' to='starbuck@moby-dick.lit' type='subscribe'/>
]]></example>
<p>Naturally, based on the JID of the sender, it is possible for the client to pull information about the sender from a persistent data store such as an LDAP database, &jep0054; node, or <cite>JEP-0154</cite> store. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender:</p>
<p>Naturally, based on the JID of the sender, it is possible for the client to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or <cite>XEP-0154</cite> store. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender:</p>
<example caption='Including Nickname with Subscription Request'><![CDATA[
<presence from='narrator@moby-dick.lit' to='starbuck@moby-dick.lit' type='subscribe'>
<nick xmlns='http://jabber.org/protocol/nick'>Ishmael</nick>
@ -180,7 +180,7 @@
]]></example>
</section2>
<section2 topic='Multi-User Chat' anchor='muc'>
<p>&jep0045; defines a protocol for groupchat rooms. A user specifies a "room nickname" when joining such a room (the resource identifier of the 'to' address):</p>
<p>&xep0045; defines a protocol for groupchat rooms. A user specifies a "room nickname" when joining such a room (the resource identifier of the 'to' address):</p>
<example caption='A Basic Room Join Request'><![CDATA[
<presence from='narrator@moby-dick.lit/pda' to='pequod@muc.moby-dick.lit/narrator'/>
]]></example>
@ -220,7 +220,7 @@
]]></example>
</section2>
<section2 topic='Waiting Lists' anchor='waitlist'>
<p>&jep0130; defines a protocol that enables a user to be informed when a contact signs up for an IM account. The user MAY include his or her nick in the request so that the contact can associate a nickname with the request.</p>
<p>&xep0130; defines a protocol that enables a user to be informed when a contact signs up for an IM account. The user MAY include his or her nick in the request so that the contact can associate a nickname with the request.</p>
<example caption="IM User Requests Addition of Contact to WaitingList"><![CDATA[
<iq type='set'
from='narrator@moby-dick.lit'
@ -278,7 +278,7 @@
]]></example>
</section2>
<section2 topic='Nickname Management' anchor='manage'>
<p>In order for a user to modify his or her nickname and notify contacts of that change, it is RECOMMENDED for clients to use &jep0163; (a.k.a. PEP).</p>
<p>In order for a user to modify his or her nickname and notify contacts of that change, it is RECOMMENDED for clients to use &xep0163; (a.k.a. PEP).</p>
<example caption='User Publishes Updated Nickname to PEP Node'><![CDATA[
<iq from='narrator@moby-dick.lit/pda'
type='set'
@ -312,7 +312,7 @@
.
.
]]></example>
<p>If a JEP-0163-compliant personal eventing service is not available, a client SHOULD use a standalone &jep0060; service.</p>
<p>If a XEP-0163-compliant personal eventing service is not available, a client SHOULD use a standalone &xep0060; service.</p>
<example caption='User Publishes Updated Nickname to PubSub Node'><![CDATA[
<iq from='narrator@moby-dick.lit/pda'
to='pubsub.mody-dick.lit'
@ -347,7 +347,7 @@
.
.
]]></example>
<p>If a client does not support <cite>JEP-0060</cite> or the subset thereof specified in <cite>JEP-0163</cite>, it MAY send one &MESSAGE; stanza to each of its contacts, containing the updated nickname (note: the client SHOULD send the messages in a staggered fashion in order to avoid server-enforced rate limiting, commonly known as "karma").</p>
<p>If a client does not support <cite>XEP-0060</cite> or the subset thereof specified in <cite>XEP-0163</cite>, it MAY send one &MESSAGE; stanza to each of its contacts, containing the updated nickname (note: the client SHOULD send the messages in a staggered fashion in order to avoid server-enforced rate limiting, commonly known as "karma").</p>
<example caption='Nickname Change Notification via Message'><![CDATA[
<message from='narrator@moby-dick.lit/pda' to='starbuck@moby-dick.lit'>
<nick xmlns='http://jabber.org/protocol/nick'>CallMeIshmael</nick>
@ -359,15 +359,15 @@
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>An IM client MAY use the user's own nickname as all or part of the "display name" shown to the user of that client (e.g., as the sending name in one-to-one chats and groupchats). For example, if the user whose JID is narrator@moby-dick.lit asserts that his nickname is "Ishmael", that user's client may show "Ishmael" as all or part of the user's display name. How the client shall store the display name is out of scope for this document; possible mechanisms include the user's local vCard, an organizational LDAP directory, &jep0049;, or <cite>JEP-0154</cite>.</p>
<p>An IM client MAY use the user's own nickname as all or part of the "display name" shown to the user of that client (e.g., as the sending name in one-to-one chats and groupchats). For example, if the user whose JID is narrator@moby-dick.lit asserts that his nickname is "Ishmael", that user's client may show "Ishmael" as all or part of the user's display name. How the client shall store the display name is out of scope for this document; possible mechanisms include the user's local vCard, an organizational LDAP directory, &xep0049;, or <cite>XEP-0154</cite>.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>A nickname is a memorable, friendly name asserted by a user. There is no guarantee that any given nickname will be unique even within a particulat community (such as an enterprise or university), let alone across the Internet through federation of communities. Clients SHOULD warn users that nicknames asserted by contacts are not unique and that nickname collisions are possible. Clients also MUST NOT depend on nicknames to validate the identity of contacts; instead, nicknames SHOULD be used in conjunction with JIDs (which are globally unique) and user-assigned handles (which are private and unique) as described in <cite>JEP-0165</cite> in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.</p>
<p>A nickname is a memorable, friendly name asserted by a user. There is no guarantee that any given nickname will be unique even within a particulat community (such as an enterprise or university), let alone across the Internet through federation of communities. Clients SHOULD warn users that nicknames asserted by contacts are not unique and that nickname collisions are possible. Clients also MUST NOT depend on nicknames to validate the identity of contacts; instead, nicknames SHOULD be used in conjunction with JIDs (which are globally unique) and user-assigned handles (which are private and unique) as described in <cite>XEP-0165</cite> in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/nick' in its registry of protocol namespaces (see &NAMESPACES;).</p>
</section2>
@ -385,7 +385,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0172: http://www.jabber.org/jeps/jep-0172.html
XEP-0172: http://www.xmpp.org/extensions/xep-0172.html
</xs:documentation>
</xs:annotation>
@ -396,6 +396,6 @@
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Ian Paterson for his feedback.</p>
<p>Unbeknownst to the authors of this document, work on user nicknames was previously done by Richard Dobson (see &lt;<link url='http://richard.dobson-i.net/jep.php?html=jep-01xx.xml'>http://richard.dobson-i.net/jep.php?html=jep-01xx.xml</link>&gt;).</p>
<p>Unbeknownst to the authors of this document, work on user nicknames was previously done by Richard Dobson (see &lt;<link url='http://richard.dobson-i.net/xep.php?html=xep-01xx.xml'>http://richard.dobson-i.net/xep.php?html=xep-01xx.xml</link>&gt;).</p>
</section1>
</jep>
</xep>

34
xep-0173.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Pubsub Subscription Storage</title>
<abstract>This JEP defines a protocol for storing subscriptions to Pubsub nodes.</abstract>
<abstract>This document defines an XMPP protocol extension for storing subscriptions to Pubsub nodes.</abstract>
&LEGALNOTICE;
<number>0173</number>
<status>Deferred</status>
@ -16,8 +16,8 @@
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0049</spec>
<spec>JEP-0060</spec>
<spec>XEP-0049</spec>
<spec>XEP-0060</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -32,7 +32,7 @@
<version>0.1</version>
<date>2006-02-09</date>
<initials>psa</initials>
<remark><p>Initial JEP version; changed title to Pubsub Subscription Storage; changed namespace to storage:pubsubs for consistency with other storage JEPs.</p></remark>
<remark><p>Initial version; changed title to Pubsub Subscription Storage; changed namespace to storage:pubsubs for consistency with other storage XEPs.</p></remark>
</revision>
<revision>
<version>0.0.4</version>
@ -60,7 +60,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&jep0060; allows Jabber entities to subscribe to various kinds of information, but provides no way of remembering which nodes a user has subscribed to. Other protocols (e.g. &jep0080;, &jep0084;) allow information about a certain entity to be published to a Pubsub node. These protocols use &jep0030; to allow other entities to find the pubsub node used by a certain entity, but provide no way of performing the opposite mapping, from pubsub node to information source. This JEP attempts to fill that void, using &jep0049; for storing information about subscriptions.</p>
<p>&xep0060; allows Jabber entities to subscribe to various kinds of information, but provides no way of remembering which nodes a user has subscribed to. Other protocols (e.g. &xep0080;, &xep0084;) allow information about a certain entity to be published to a Pubsub node. These protocols use &xep0030; to allow other entities to find the pubsub node used by a certain entity, but provide no way of performing the opposite mapping, from pubsub node to information source. This document attempts to fill that void, using &xep0049; for storing information about subscriptions.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This protocol enables Jabber clients to do the following:</p>
@ -112,8 +112,8 @@
</section2>
<section2 topic='Updating Subscriptions' anchor='updating'>
<p>Due to the nature of JEP-0049, incremental updates are not possible; a client MUST send the entire &lt;subscriptions/&gt; node for each update. Before performing the update, the client SHOULD retrieve the stored subscriptions, and incorporate any changes.</p>
<p>In this example, the user has just subscribed to Romeo's tune (see &jep0118;). Assuming that retrieving happened as in the previous use case, updating the subscriptions proceeds as follows:</p>
<p>Due to the nature of XEP-0049, incremental updates are not possible; a client MUST send the entire &lt;subscriptions/&gt; node for each update. Before performing the update, the client SHOULD retrieve the stored subscriptions, and incorporate any changes.</p>
<p>In this example, the user has just subscribed to Romeo's tune (see &xep0118;). Assuming that retrieving happened as in the previous use case, updating the subscriptions proceeds as follows:</p>
<example caption='Client sends updated subscriptions'><![CDATA[
<iq type='set' id='update1'>
<query xmlns='jabber:iq:private'>
@ -162,17 +162,17 @@
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Pubsub events offer an opportunity to spoof sender addresses e.g. through 'replyto' data (as specified by the &jep0033; protocol). This protocol attempts to close that hole. It does so by the following rules and assumptions:</p>
<p>Pubsub events offer an opportunity to spoof sender addresses e.g. through 'replyto' data (as specified by the &xep0033; protocol). This protocol attempts to close that hole. It does so by the following rules and assumptions:</p>
<ul>
<li>A client MUST add mappings (i.e. associations between a publisher's JID and a pubsub node) only from trustworthy sources, i.e. published disco items (see &jep0030;). This relies on disco information not being cracked or falsified.</li>
<li>A client MUST add mappings (i.e. associations between a publisher's JID and a pubsub node) only from trustworthy sources, i.e. published disco items (see &xep0030;). This relies on disco information not being cracked or falsified.</li>
<li>A client MUST retrieve mappings only from trustworthy sources, i.e. private XML storage. This assumes that no-one but the user is able to change such information.</li>
</ul>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this JEP.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this document.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[
@ -215,4 +215,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

14
xep-0174.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Link-Local Messaging</title>
<abstract>This document describes how to establish XMPP-like communications over local networks using zero-configuration networking.</abstract>
@ -71,7 +71,7 @@
<version>0.1</version>
<date>2006-02-09</date>
<initials>psa</initials>
<remark><p>Initial JEP version; changed title to Link-Local Messaging.</p></remark>
<remark><p>Initial version; changed title to Link-Local Messaging.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
@ -298,10 +298,10 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<section1 topic='IANA Considerations' anchor='iana'>
<p>The p2pj port number 5298 is not included in the &ianaports; maintained by &IANA;. The author will investigate whether that port number (or some other port number) needs to be registered.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Justin Karneges, Jens Alfke, and Marc Krochmal for their input.</p>
</section1>
</jep>
</xep>

12
xep-0175.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Best Practices for Use of SASL ANONYMOUS</title>
<abstract>This document specifies best practices for use of the SASL ANONYMOUS mechanism in the context of client authentication with an XMPP server.</abstract>
@ -149,7 +149,7 @@
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This JEP requires no interaction with the &REGISTRAR;.</p>
</section1>
</jep>
</xep>

32
xep-0176.xml
View File

@ -1,11 +1,11 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY ice10 "<cite>ICE-10</cite>">
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jingle ICE Transport</title>
<abstract>This document defines a Jingle transport method that results in sending data between two entities using Interactive Connectivity Establishment (ICE) methodology.</abstract>
@ -17,7 +17,7 @@
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0166</spec>
<spec>XEP-0166</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -37,7 +37,7 @@
<version>0.3</version>
<date>2006-07-12</date>
<initials>se/psa</initials>
<remark><p>Specified that DTMF must use in-band signalling (JEP-0181).</p></remark>
<remark><p>Specified that DTMF must use in-band signalling (XEP-0181).</p></remark>
</revision>
<revision>
<version>0.2</version>
@ -49,11 +49,11 @@
<version>0.1</version>
<date>2006-03-01</date>
<initials>psa/jb</initials>
<remark>Initial JEP version (split from JEP-0166).</remark>
<remark>Initial JEP version (split from XEP-0166).</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&jep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor content (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data connections between XMPP entities, using the &ice; methodology currently being developed within the IETF.</p>
<p>&xep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor content (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data connections between XMPP entities, using the &ice; methodology currently being developed within the IETF.</p>
<p>The process for ICE negotiation is largely the same in Jingle as it is in draft-ietf-mmusic-ice. There are several differences:</p>
<ul>
<li>Instead of using SIP as the signalling channel, Jingle uses XMPP as the signalling channel.</li>
@ -75,7 +75,7 @@
</section1>
<section1 topic='Protocol Description' anchor='protocol'>
<section2 topic='Transport Initiation' anchor='protocol-initiate'>
<p>In order for the initiator in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in <cite>JEP-0166</cite>. This stanza MUST include at least one transport method. If the initiator wishes to negotiate the ICE transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/ice' namespace.</p>
<p>In order for the initiator in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in <cite>XEP-0166</cite>. This stanza MUST include at least one transport method. If the initiator wishes to negotiate the ICE transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/ice' namespace.</p>
<example caption="Initiation"><![CDATA[
<iq to='juliet@capulet.com/balcony' from='romeo@montague.net/orchard' id='jingle1' type='set'>
<jingle xmlns='http://jabber.org/protocol/jingle'
@ -96,13 +96,13 @@
]]></example>
</section2>
<section2 topic='Target Entity Response' anchor='protocol-response'>
<p>As described in <cite>JEP-0166</cite>, to provisionally accept the session initiation request, the responder returns an IQ-result:</p>
<p>As described in <cite>XEP-0166</cite>, to provisionally accept the session initiation request, the responder returns an IQ-result:</p>
<example caption="Target Entity Provisionally Accepts the Session Request"><![CDATA[
<iq type='result' from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard' id='jingle1'/>
]]></example>
</section2>
<section2 topic='ICE Negotiation' anchor='protocol-negotiate'>
<p>If the responder provisionally accepts the session initiation request as shown above, both initiator and responder MUST immediately negotiate connectivity over the ICE transport by exchanging XML-formatted candidate transports for the channel. This negotiation proceeds immediately in order to maximize the possibility that media can be exchanged as quickly as possible. <note>Concurrent with negotiation of the ICE candidates, it is possible for the initiator and responder to negotiate which content types the session will include, which transport methods will be tried for each content type, etc. Those negotiation flows are shown in <cite>JEP-0166</cite>. This JEP specifies only negotiation of the ICE transport method.</note></p>
<p>If the responder provisionally accepts the session initiation request as shown above, both initiator and responder MUST immediately negotiate connectivity over the ICE transport by exchanging XML-formatted candidate transports for the channel. This negotiation proceeds immediately in order to maximize the possibility that media can be exchanged as quickly as possible. <note>Concurrent with negotiation of the ICE candidates, it is possible for the initiator and responder to negotiate which content types the session will include, which transport methods will be tried for each content type, etc. Those negotiation flows are shown in <cite>XEP-0166</cite>. This JEP specifies only negotiation of the ICE transport method.</note></p>
<p>The candidate syntax and negotiation flow are described below.</p>
<section3 topic='Syntax of Candidate Element' anchor='protocol-negotiate-candidate'>
<p>The following is an example of the candidate format:</p>
@ -378,7 +378,7 @@
</section1>
<section1 topic='Service Discovery' anchor='disco'>
<p>If an entity supports this specification, it MUST return a feature of "http://jabber.org/protocol/jingle/transport/ice" in response to &jep0030; information requests.</p>
<p>If an entity supports this specification, it MUST return a feature of "http://jabber.org/protocol/jingle/transport/ice" in response to &xep0030; information requests.</p>
<p>As mentioned in the <link url='#deploy'>Deployment Notes</link> of this document, server administrators may wish to deploy STUN servers in order to ease the process of negotiating use of the Jingle ICE transport. If a STUN server is accessible via XMPP, it SHOULD be advertised by returning an appropriate item in response to service discovery item requests sent to the address of an XMPP server:</p>
<example caption="Service Discovery of STUN Server (1)"><![CDATA[
<iq from='romeo@montague.net/orchard' to='montague.net' id='disco1' type='get'>
@ -410,7 +410,7 @@
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='DTMF' anchor='impl-dtmf'>
<p>If it is necessary to send Dual Tone Multi-Frequency (DTMF) tones, it is REQUIRED to use the XML format specified &jep0181;.</p>
<p>If it is necessary to send Dual Tone Multi-Frequency (DTMF) tones, it is REQUIRED to use the XML format specified &xep0181;.</p>
</section2>
</section1>
@ -442,7 +442,7 @@
A method for negotiation of out-of-band connections with built-in NAT and firewall traversal,
similar to the IETF's Interactive Connectivity Establishment (ICE) methodology.
</desc>
<doc>JEP-0176</doc>
<doc>XEP-0176</doc>
</transport>
]]></code>
</section2>
@ -455,7 +455,7 @@
<type>
<name>stun</name>
<desc>a STUN (Simple Traversal of UDP Through NATs) service per RFC 3489</desc>
<doc>JEP-0176</doc>
<doc>XEP-0176</doc>
</type>
</category>
]]></code>
@ -519,4 +519,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

30
xep-0177.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jingle Raw UDP Transport</title>
<abstract>This document defines a Jingle transport method that results in sending data over a raw User Datagram Protocol (UDP) connection.</abstract>
@ -16,7 +16,7 @@
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0166</spec>
<spec>XEP-0166</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -36,11 +36,11 @@
<version>0.1</version>
<date>2006-03-01</date>
<initials>psa/jb</initials>
<remark>Initial JEP version (split from JEP-0166).</remark>
<remark>Initial version (split from XEP-0166).</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&jep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor content (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data between XMPP entities using a raw User Datagram Protocol (UDP) connection (see &rfc0768;).</p>
<p>&xep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor content (session) types, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data between XMPP entities using a raw User Datagram Protocol (UDP) connection (see &rfc0768;).</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The Jingle transport method defined herein is designed to meet the following requirements:</p>
@ -52,7 +52,7 @@
</section1>
<section1 topic='Protocol Description' anchor='protocol'>
<section2 topic='Transport Initiation' anchor='protocol-initiate'>
<p>In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in <cite>JEP-0166</cite>. This stanza MUST include at least one transport methods. If the initiating entity wishes to negotiate the Raw UDP transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/raw-udp' namespace.</p>
<p>In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in <cite>XEP-0166</cite>. This stanza MUST include at least one transport methods. If the initiating entity wishes to negotiate the Raw UDP transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/raw-udp' namespace.</p>
<example caption="Initiation Example"><![CDATA[
<iq to='juliet@capulet.com/balcony' from='romeo@montague.net/orchard' id='jingle1' type='set'>
<jingle xmlns='http://jabber.org/protocol/jingle'
@ -66,13 +66,13 @@
]]></example>
</section2>
<section2 topic='Target Entity Response' anchor='protocol-response'>
<p>As described in <cite>JEP-0166</cite>, to provisionally accept the session initiation request, the target entity returns an IQ-result:</p>
<p>As described in <cite>XEP-0166</cite>, to provisionally accept the session initiation request, the target entity returns an IQ-result:</p>
<example caption="Target Entity Provisionally Accepts the Session Request"><![CDATA[
<iq type='result' from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard' id='jingle1'/>
]]></example>
</section2>
<section2 topic='Exchanging Address Information' anchor='protocol-addresses'>
<p>Once the session is provisionally accepted, each entity should send one &TRANSPORT; element in a transport-info meessage, containing exactly one &CANDIDATE; element per channel, whose 'ip' and 'port' attributes specify the IP address and port number of the candidate that the initiator has reason to believe will be most likely to succeed for that channel. (Note: In older versions of JEP-0166, this was referrred to as the "default candidate".) This is not necessarily the initiator's preferred address for communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. To determine reachability, the client needs classify ahead of time the permissiveness of the firewall or network address translator (NAT) it is behind, if any. If the NAT is symmetric (not permissive), the candidate SHOULD specify a relay address. Otherwise it SHOULD be an address derived via prior discovery using &rfc3489;, which will be an address on the outside of the firewall or NAT.</p>
<p>Once the session is provisionally accepted, each entity should send one &TRANSPORT; element in a transport-info meessage, containing exactly one &CANDIDATE; element per channel, whose 'ip' and 'port' attributes specify the IP address and port number of the candidate that the initiator has reason to believe will be most likely to succeed for that channel. (Note: In older versions of XEP-0166, this was referrred to as the "default candidate".) This is not necessarily the initiator's preferred address for communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. To determine reachability, the client needs classify ahead of time the permissiveness of the firewall or network address translator (NAT) it is behind, if any. If the NAT is symmetric (not permissive), the candidate SHOULD specify a relay address. Otherwise it SHOULD be an address derived via prior discovery using &rfc3489;, which will be an address on the outside of the firewall or NAT.</p>
<example caption="Address Exchange Example"><![CDATA[
<iq to='juliet@capulet.com/balcony' from='romeo@montague.net/orchard' id='jingle2' type='set'>
<jingle xmlns='http://jabber.org/protocol/jingle'
@ -101,21 +101,21 @@
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/raw-udp' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Jingle Transport Methods' anchor='registrar-transports'>
<p>The Jabber Registrar shall include "http://jabber.org/protocol/jingle/transport/raw-udp" in its registry of Jingle transport methods. The registry submission is as follows:</p>
<p>The XMPP Registrar shall include "http://jabber.org/protocol/jingle/transport/raw-udp" in its registry of Jingle transport methods. The registry submission is as follows:</p>
&REGPROCESS;
<code><![CDATA[
<transport>
<name>raw-udp</name>
<desc>A method for exchanging data over a raw UDP connection.</desc>
<doc>JEP-0176</doc>
<doc>XEP-0176</doc>
</transport>
]]></code>
</section2>
@ -160,4 +160,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

20
xep-0178.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Best Practices for Use of SASL EXTERNAL</title>
<abstract>This document specifies best practices for use of the SASL EXTERNAL mechanism within XMPP.</abstract>
@ -38,7 +38,7 @@
<version>0.1</version>
<date>2006-03-09</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
@ -323,16 +323,16 @@
<p>The SASL EXTERNAL mechanism can be used outside the context of X.509 certificates, for example via Internet Protocol Security (IPSec) as specified in &rfc4301;. A future version of this specification may document best practices for use of SASL EXTERNAL outside the context of the X.509 infrastructure.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This JEP introduces no security considerations or concerns above and beyond those discussed in <cite>RFC 3920</cite>.</p>
<p>This document introduces no security considerations or concerns above and beyond those discussed in <cite>RFC 3920</cite>.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<p>This JEP requires no interaction with the &REGISTRAR;.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
<section1 topic='Author Note' anchor='authornote'>
<p>Peter Millard, co-author of the initial version of this specification, died on April 26, 2006. The remaining author appreciates his assistance in defining the best practices described herein.</p>
</section1>
</jep>
</xep>

30
xep-0179.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jingle IAX Transport Method</title>
<abstract>This document defines a Jingle transport method that results in using the Inter-Asterisk eXchange protocol (IAX) for the final communication.</abstract>
@ -15,7 +15,7 @@
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0166</spec>
<spec>XEP-0166</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -37,7 +37,7 @@
<version>0.1</version>
<date>2006-03-09</date>
<initials>psa</initials>
<remark><p>Initial JEP version.</p></remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.4</version>
@ -65,7 +65,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&jep0166; 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. The current document defines a transport method for establishing and managing &iax; sessions between XMPP entities.</p>
<p>&xep0166; 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. The current document defines a transport method for establishing and managing &iax; sessions between XMPP entities.</p>
<p>IAX is a peer-to-peer media and signaling protocol, where the endpoints maintain state machines. With respect to media, sequencing and timing information is included into IAX frames, without the use of Real-Time Transport Protocol (RTP) for the media. <note>IAX is a binary protocol; this design choice was made for bandwidth efficiency.</note> The IAX protocol handles the signaling and, when the call is accepted by both peers, the media passes between the two hosts. With this approach, IAX doesn't suffer from NAT traversal problems associated with others protocols like SIP or other related protocols.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
@ -78,7 +78,7 @@
</section1>
<section1 topic='Protocol Description' anchor='protocol'>
<section2 topic='Transport Initiation' anchor='protocol-initiate'>
<p>In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in <cite>JEP-0166</cite>. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the IAX transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/iax' namespace.</p>
<p>In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in <cite>XEP-0166</cite>. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the IAX transport, it MUST include an empty &TRANSPORT; child element qualified by the 'http://jabber.org/protocol/jingle/transport/iax' namespace.</p>
<example caption="Initiation Example, sended by Romeo"><![CDATA[
<iq to='juliet@capulet.com/balcony'
@ -98,7 +98,7 @@
</section2>
<section2 topic='Target Entity Response' anchor='protocol-response'>
<p>As described in <cite>JEP-0166</cite>, to provisionally accept the session initiation request, the target entity returns an IQ-result:</p>
<p>As described in <cite>XEP-0166</cite>, to provisionally accept the session initiation request, the target entity returns an IQ-result:</p>
<example caption="Target Entity Provisionally Accepts the Session Request"><![CDATA[
<iq type='result' from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard' id='jingle1'/>
]]></example>
@ -161,28 +161,28 @@
<p>In both cases, the Asterisk PBX has to be logged into the Jabber network and implement the Jingle extension like a channel (Asterisk terminology).</p>
</section2>
<section2 topic='DTMF' anchor='impl-DTMF'>
<p>If it is necessary to send Dual Tone Multi-Frequency (DTMF) tones, it is RECOMMENDED to use the IAX-native methods specified in <cite>draft-ietf-guy-iax</cite>. The XML format specified &jep0181; MAY be used only as a fallback.</p>
<p>If it is necessary to send Dual Tone Multi-Frequency (DTMF) tones, it is RECOMMENDED to use the IAX-native methods specified in <cite>draft-ietf-guy-iax</cite>. The XML format specified &xep0181; MAY be used only as a fallback.</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>To follow.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/iax' and 'http://jabber.org/protocol/jingle/info/iax' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Jingle IAX Transport Description' anchor='registrar-transport'>
<p>The Jabber Registrar shall include the name "iax" in its registry of Jingle transport descriptions. The registration is as follows:</p>
<p>The XMPP Registrar shall include the name "iax" in its registry of Jingle transport descriptions. The registration is as follows:</p>
<code><![CDATA[
<transport>
<name>iax</name>
<desc>Jingle IAX sessions.</desc>
<doc>JEP-0179</doc>
<doc>XEP-0179</doc>
</transport>
]]></code>
</section2>
</section1>
</jep>
</xep>