moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00
Code Issues Releases Wiki Activity

0.16

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2856 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-03-09 17:47:04 +00:00
parent ee605b2027
commit 68f03fc9b1
1 changed files with 36 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
xep-0177.xml
View File

@ -27,6 +27,12 @@
&scottlu;
&hildjj;
&seanegan;
<revision>
<version>0.16</version>
<date>2009-03-09</date>
<initials>psa</initials>
<remark><p>Minor changes to track modifications to XEP-0166; updated security considerations for consistency with XEP-0176.</p></remark>
</revision>
<revision>
<version>0.15</version>
<date>2009-02-11</date>
@ -180,10 +186,10 @@ INITIATOR RESPONDER
<p>In order for the initiator in a Jingle exchange to start the negotiation, it sends a Jingle "session-initiate" stanza that includes at least one content type, as described in <cite>XEP-0166</cite>. If the initiator wishes to negotiate the Raw UDP transport for a given content type, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:raw-udp:1' namespace &VNOTE;, which MUST <note>This is required to avoid a round trip and help expedite the negotiation.</note> include the initiator's Raw UDP candidate via the 'ip', 'port', 'generation', and 'id' attributes of the &CANDIDATE; element. The &TRANSPORT; element MAY include more than one &CANDIDATE; element (typically one for RTP and another for RTCP).</p>
<example caption="Initiation"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='jingle1'
id='tp2hd816'
to='juliet@capulet.lit/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:0'
<jingle xmlns='urn:xmpp:jingle:1'
action='session-initiate'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
@ -228,17 +234,17 @@ INITIATOR RESPONDER
<p>As described in <cite>XEP-0166</cite>, to acknowledge the session initiation request, the responder returns an IQ-result:</p>
<example caption="Responder acknowledges the session-initiate request"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='jingle1'
id='tp2hd816'
to='romeo@montague.lit/orchard'
type='result'/>
]]></example>
<p>As soon as the responding user agrees to proceed with the session, the responding client MUST send a Jingle session-accept to the initiator. This session-accept message MAY include one or more candidates generated by the responder.</p>
<p>Depending on the application type, a user agent controlled by a human user might need to wait for the user to affirm a desire to proceed with the session before continuing. When the user agent has received such affirmation (or if the user agent can automatically proceed for any reason, e.g. because no human intervention is expected or because a human user has configured the user agent to automatically accept sessions with a given entity), it returns a Jingle session-accept message. This message MUST contain a &TRANSPORT; element qualified by the 'urn:xmpp:jingle:transports:raw-udp:1' namespace, which SHOULD in turn contain one &CANDIDATE; element for each Raw UDP candidate generated by or known to the responder.</p>
<example caption="Responder definitively accepts the session"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='accept1'
id='hs81w639'
to='romeo@montague.lit/orchard'
type='set'>
<jingle xmlns='urn:xmpp:jingle:0'
<jingle xmlns='urn:xmpp:jingle:1'
action='session-accept'
initiator='romeo@montague.lit/orchard'
responder='juliet@capulet.lit/balcony'
@ -267,7 +273,7 @@ INITIATOR RESPONDER
<p>The initiator then acknowledges the session acceptance.</p>
<example caption="Initiator acknowledges session acceptance"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='accept1'
id='hs81w639'
to='juliet@capulet.lit/balcony'
type='result'/>
]]></example>
@ -278,10 +284,10 @@ INITIATOR RESPONDER
<p>An implementation SHOULD enforce a timeout on receipt of media, such that if no media is received from the other party within a reasonable period of time, the implementation will consider the session to have failed and therefore send to the other party a Jingle "session-terminate" action with a reason code of &lt;timeout/&gt;.</p>
<example caption="Responder terminates the session"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='term1'
id='rig16s95'
to='romeo@montague.lit/orchard'
type='set'>
<jingle xmlns='urn:xmpp:jingle:0'
<jingle xmlns='urn:xmpp:jingle:1'
action='session-terminate'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
@ -292,7 +298,7 @@ INITIATOR RESPONDER
<p>The other party then acknowledges termination of the session.</p>
<example caption="Initiator acknowledges termination"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='term1'
id='rig16s95'
to='juliet@capulet.lit/balcony'
type='result'/>
]]></example>
@ -300,10 +306,10 @@ INITIATOR RESPONDER
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>If an entity supports the Jingle Raw UDP transport, it MUST return a feature of "urn:xmpp:jingle:transports:raw-udp:1" &VNOTE; in response to &xep0030; information requests.</p>
<p>To advertise its support for the Jingle ICE-UDP Transport Method, when replying to &xep0030; information requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., "urn:xmpp:jingle:transports:raw-udp:1" for this version and "urn:xmpp:jingle:transports:raw-udp:0" for the previous version &VNOTE;.</p>
<example caption="Service discovery information request"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='disco1'
id='uw72g176'
to='juliet@capulet.lit/balcony'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@ -311,11 +317,16 @@ INITIATOR RESPONDER
]]></example>
<example caption="Service discovery information response"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='disco1'
id='uw72g176'
to='romeo@montague.lit/orchard'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:jingle:1'/>
<feature var='urn:xmpp:jingle:transports:raw-udp:0'/>
<feature var='urn:xmpp:jingle:transports:raw-udp:1'/>
<feature var='urn:xmpp:jingle:apps:rtp:1'/>
<feature var='urn:xmpp:jingle:apps:rtp:audio'/>
<feature var='urn:xmpp:jingle:apps:rtp:video'/>
</query>
</iq>
]]></example>
@ -323,7 +334,18 @@ INITIATOR RESPONDER
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>In order to secure the data stream that is negotiated via the Jingle Raw UDP transport, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged (for details regarding RTP sessions, refer to <cite>XEP-0167</cite>).</p>
<section2 topic='Sharing IP Addresses' anchor='security-sharing'>
<p>By definition, the exchange of transport candidates results in exposure of the sender's IP addresses, which comprise a form of personally identifying information. A Jingle client MUST enable a user to control which entities will be allowed to receive such information. If a human user explicitly accepts a session request, then the client SHOULD consider that action to imply approval of IP address sharing. However, waiting for a human user to explicitly accept the session request can result in delays during session setup, since it is more efficient to immediately begin sharing transport candidates. Therefore, it is RECOMMENDED for the client to immediately send transport candidates to a contact (without waiting for explicit user approval of the session request) in the following cases:</p>
<ol>
<li>The user has permanently and formally authorized the contact to view the user's presence information via a presence subscription as reflected in an XMPP roster item (see &xmppim;).</li>
<li>The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in <cite>RFC 3921</cite>.</li>
<li>The user has explicitly added the contact to a "whitelist" of entities who are allowed to access the user's personally-identifying information.</li>
</ol>
</section2>
<section2 topic='Encryption of Media' anchor='security-media'>
<p>A Jingle implementation SHOULD support security preconditions that are enforced before application media is allowed to flow over a UDP association, such as those described in &xtls;.</p>
<p>Application types that use the Jingle Raw UDP transport method MAY also define their own application-specific encryption methods, such as the Secure Real-time Transport Protocol (SRTP) for RTP exchanges as described in &xep0167;.</p>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>