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

typos

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3001 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-04-06 23:21:51 +00:00
parent 094b66f592
commit 30c0e335dc
1 changed files with 46 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
xep-0166.xml
View File

@ -354,7 +354,7 @@
</section1> </section1>
<section1 topic='How It Works' anchor='howitworks'> <section1 topic='How It Works' anchor='howitworks'>
<p>This section provides a friendly introduction to Jingle.</p> <p>This section provides a friendly introduction to Jingle.</p>
<p>In essence, Jingle enables two XMPP entities (e.g., romeo@montague.lit and juliet@capulet.lit) to set up, manage, and tear down a multimedia session. The negotiation takes place over XMPP, and the media transfer typically takes place outside of XMPP. A simplified session flow would be as follows: <note>Naturally, more complex scenarios are possible; such scenarios are described in other specifications, such as <cite>XEP-0167</cite> for voice and video chat.</note></p> <p>In essence, Jingle enables two XMPP entities (e.g., romeo@montague.lit and juliet@capulet.lit) to set up, manage, and tear down a multimedia session. The negotiation takes place over XMPP, and the media transfer typically takes place outside of XMPP. A simplified session flow would be as follows: <note>Naturally, more complex scenarios are possible; such scenarios are described in other specifications, such as <cite>Jingle RTP Sessions</cite> for voice and video chat.</note></p>
<code><![CDATA[ <code><![CDATA[
Romeo Juliet Romeo Juliet
| | | |
@ -392,7 +392,7 @@ Romeo Juliet
</iq> </iq>
]]></example> ]]></example>
<p>In this example, the initiator (romeo@montague.lit/orchard) sends a session initiation offer to the responder (juliet@capulet.lit/balcony), where the session is defined as the exchange of "stub" media over a "stub" transport.</p> <p>In this example, the initiator (romeo@montague.lit/orchard) sends a session initiation offer to the responder (juliet@capulet.lit/balcony), where the session is defined as the exchange of "stub" media over a "stub" transport.</p>
<p>After the responding client acknowledges receipt of the session-initiate message, it prompts the responding user (if any) to choose whether she wants to proceed with the session (however, it does not need to prompt the user if for example she has configured her client to automatically accept session requests from this particular initiator). If she wants to proceed she selects the appropriate interface element and her client sends a session-accept message to the initiator.</p> <p>After the responding client acknowledges receipt of the session-initiate message (not shown here), it prompts the responding user (if any) to choose whether she wants to proceed with the session (however, it does not need to prompt the user if for example she has configured her client to automatically accept session requests from this particular initiator). If she wants to proceed she selects the appropriate interface element and her client sends a session-accept message to the initiator.</p>
<example caption="Responder definitively accepts the session"><![CDATA[ <example caption="Responder definitively accepts the session"><![CDATA[
<iq from='juliet@capulet.lit/balcony' <iq from='juliet@capulet.lit/balcony'
id='rc61n59s' id='rc61n59s'
@ -427,8 +427,8 @@ Romeo Juliet
</jingle> </jingle>
</iq> </iq>
]]></example> ]]></example>
<p>The initiator's acknowledges receipt of the session-terminate message (not shown here) and the session is ended.</p> <p>The initiating client acknowledges receipt of the session-terminate message (not shown here) and the session is ended.</p>
<p>We now "fill in the blanks" for the &DESCRIPTION; and &TRANSPORT; elements with a more complex example: a voice chat session, where application type is a Jingle RTP session (with several different codec possibilities) and the transport method is &xep0176;.</p> <p>We now "fill in the blanks" for the &DESCRIPTION; and &TRANSPORT; elements with a more complex example: a voice chat session, where the application type is a Jingle RTP session (with several different codec possibilities) and the transport method is ICE-UDP.</p>
<example caption="Initiator sends session-initiate"><![CDATA[ <example caption="Initiator sends session-initiate"><![CDATA[
<iq from='romeo@montague.lit/orchard' <iq from='romeo@montague.lit/orchard'
id='ph37a419' id='ph37a419'
@ -594,7 +594,7 @@ Romeo Juliet
</tr> </tr>
<tr> <tr>
<td>Transport Method</td> <td>Transport Method</td>
<td>The method for establishing data stream(s) between entities. Possible transports might include ICE-UDP, ICE-TCP, Raw UDP, In-Band Bytestreams, SOCKS5 Bytestreams, etc. This is the 'how' of the session. In Jingle XML syntax this is the namespace of the &TRANSPORT; element. The transport method defines how to transfer bits from one host to another. Each transport method MUST specify whether it is "datagram" or "streaming" as described in the <link url='#transports'>Transport Types</link> sectio of this document.</td> <td>The method for establishing data stream(s) between entities. Possible transports might include ICE-UDP, ICE-TCP, Raw UDP, In-Band Bytestreams, SOCKS5 Bytestreams, etc. This is the 'how' of the session. In Jingle XML syntax this is the namespace of the &TRANSPORT; element. The transport method defines how to transfer bits from one host to another. Each transport method MUST specify whether it is "datagram" or "streaming" as described in the <link url='#transports'>Transport Types</link> section of this document.</td>
</tr> </tr>
</table> </table>
</section2> </section2>
@ -622,7 +622,7 @@ Romeo Juliet
<li>Optionally, the parties attempt to establish security for the transport method before using it to exchange application data.</li> <li>Optionally, the parties attempt to establish security for the transport method before using it to exchange application data.</li>
<li>Optionally, either party can add or remove content definitions, or change the direction of the media flow, using the content-add, content-remove, and content-modify messages.</li> <li>Optionally, either party can add or remove content definitions, or change the direction of the media flow, using the content-add, content-remove, and content-modify messages.</li>
<li>Optionally, either party can send session-info messages (e.g., to inform the other party that its device is ringing).</li> <li>Optionally, either party can send session-info messages (e.g., to inform the other party that its device is ringing).</li>
<li>As soon as the responder determines that data can flow over the negotiated transport (potentially only after a security precondition has been met), they start sending application data over the transport.</li> <li>As soon as the initiator and responder determine that data can flow over the negotiated transport (potentially only after a security precondition has been met), they start sending application data over the transport.</li>
</ol> </ol>
<p>Even after application data is being exchanged, the parties can adjust the session definition by sending additional Jingle messages, such as content-modify, content-remove, content-add, description-info, security-info, session-info, and transport-replace.</p> <p>Even after application data is being exchanged, the parties can adjust the session definition by sending additional Jingle messages, such as content-modify, content-remove, content-add, description-info, security-info, session-info, and transport-replace.</p>
<section2 topic='Overall Session Management' anchor='concepts-session'> <section2 topic='Overall Session Management' anchor='concepts-session'>
@ -632,39 +632,39 @@ Romeo Juliet
| |
| session-initiate | session-initiate
| |
| +------------------------+ | +---------->--------------+
|/ | |/ |
PENDING o----------------------+ | PENDING o-----------------------+ |
| | content-accept, | | | | content-accept, | |
| | content-add, | | | | content-add, | |
| | content-modify, | | | | content-modify, | |
| | content-reject, | | | | content-reject, | |
| | content-remove, | | | | content-remove, | |
| | description-info, | | | | description-info, | |
| | session-info, | | \|/ | session-info, | |
| | transport-accept, | | | | transport-accept, | |
| | transport-info, | | | | transport-info, | |
| | transport-reject, | | | | transport-reject, | |
| | transport-replace | | | | transport-replace | |
| +-------------------+ | | +-------------------+ |
| | | |
| session-accept | | session-accept \|/
| | | |
ACTIVE o----------------------+ | ACTIVE o-----------------------+ |
| | content-accept, | | | | content-accept, | |
| | content-add, | | | | content-add, | |
| | content-modify, | | | | content-modify, | |
| | content-reject, | | | | content-reject, | |
| | content-remove, | | | | content-remove, | |
| | description-info, | | | | description-info, | |
| | session-info, | | \|/ | session-info, | |
| | transport-accept, | | | | transport-accept, | |
| | transport-info, | | | | transport-info, | |
| | transport-reject, | | | | transport-reject, | |
| | transport-replace | | | | transport-replace | |
| +-------------------+ | | +-------------------+ |
| | | |
+--------------------------+ +------------>--------------+
| |
| session-terminate | session-terminate
| |
@ -676,7 +676,7 @@ PENDING o----------------------+ |
<li>ACTIVE</li> <li>ACTIVE</li>
<li>ENDED</li> <li>ENDED</li>
</ol> </ol>
<p>Note: While it is allowed to send all actions while in the PENDING state, typically the responder will send a session-accept message as quickly as possible in order to expedite the transport negotiation; see the <link url='#sec'>Security Considerations</link> section of this document regarding informatino exposure when the responder sends transport candidates to the initiator.</p> <p>Note: While it is allowed to send all actions while in the PENDING state, typically the responder will send a session-accept message as quickly as possible in order to expedite the transport negotiation; see the <link url='#sec'>Security Considerations</link> section of this document regarding information exposure when the responder sends transport candidates to the initiator.</p>
<p>The actions related to management of the overall Jingle session are as follows (detailed definitions are provided in the <link url='#def-action'>Action Attribute</link> section of this document).</p> <p>The actions related to management of the overall Jingle session are as follows (detailed definitions are provided in the <link url='#def-action'>Action Attribute</link> section of this document).</p>
<ul> <ul>
<li>content-accept -- Accept a content-add action received from another party.</li> <li>content-accept -- Accept a content-add action received from another party.</li>
@ -1126,7 +1126,7 @@ PENDING o----------------------+ |
</tr> </tr>
<tr> <tr>
<td>initiator</td> <td>initiator</td>
<td>The full JID of the entity that has initiated the session flow. This can be different from the 'from' address on the IQ-set of the session-initiate message (e.g., to handle certain interactions involving call managers, soft switches, and media relays); however, if the 'initiator' and 'from' values are different then the responder MUST NOT interact with the 'initiator' JID unless it trusts the 'initiator' JID or trusts the 'from' JID to authorize the 'initiator' JID to act on its behalf.</td> <td>The full JID of the entity that has initiated the session flow. This can be different from the 'from' address on the IQ-set of the session-initiate message (e.g., to handle certain interactions involving call managers, soft switches, and media relays); however, if the 'initiator' and 'from' values are different then the responder MUST NOT interact with the 'initiator' JID unless it trusts the 'initiator' JID or trusts the 'from' JID to authorize the 'initiator' JID to act on its behalf. For details, refer to &xep0251;.</td>
<td>REQUIRED</td> <td>REQUIRED</td>
</tr> </tr>
<tr> <tr>
@ -1180,7 +1180,7 @@ PENDING o----------------------+ |
<p>The <strong>transport-accept</strong> action is used to accept a transport-replace action received from another party.</p> <p>The <strong>transport-accept</strong> action is used to accept a transport-replace action received from another party.</p>
</section3> </section3>
<section3 topic='transport-info' anchor='def-action-transport-info'> <section3 topic='transport-info' anchor='def-action-transport-info'>
<p>The <strong>transport-info</strong> action is used to exchange transport candidates; it is mainly used in <cite>XEP-0176</cite> but might be used in other transport specifications.</p> <p>The <strong>transport-info</strong> action is used to exchange transport candidates; it is mainly used in <cite>Jingle ICE-UDP</cite> but might be used in other transport specifications.</p>
</section3> </section3>
<section3 topic='transport-reject' anchor='def-action-transport-reject'> <section3 topic='transport-reject' anchor='def-action-transport-reject'>
<p>The <strong>transport-reject</strong> action is used to reject a transport-replace action received from another party.</p> <p>The <strong>transport-reject</strong> action is used to reject a transport-replace action received from another party.</p>