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

minor corrections and clarifications

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3056 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-04-18 21:47:00 +00:00
parent 981f7530c6
commit 3dced7080a
1 changed files with 22 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
xep-0166.xml
View File

@ -678,22 +678,22 @@ PENDING o-----------------------+ |
</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 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>
<ul>
<li>content-accept -- Accept a content-add action received from another party.</li>
<li>content-add -- Add one or more new content definitions to the session.</li>
<li>content-modify -- Change the directionality of media sending.</li>
<li>content-reject -- Reject a content-add action received from another party.</li>
<li>content-remove -- Remove one or more content definitions from the session.</li>
<li>description-info -- Exchange information about parameters for an application type.</li>
<li>session-accept -- Definitively accept a session negotiation.</li>
<li>session-info -- Send session-level information, such as a ping or a ringing message.</li>
<li>session-initiate -- Request negotiation of a new Jingle session.</li>
<li>session-terminate -- End an existing session.</li>
<li>transport-accept -- Accept a transport-replace action received from another party.</li>
<li>transport-info -- Exchange transport candidates.</li>
<li>transport-reject -- Reject a transport-replace action received from another party.</li>
<li>transport-replace -- Redefine a transport method or replace it with a different method.</li>
</ul>
<dl>
<di><dt>content-accept</dt><dd>Accept a content-add action received from another party.</dd></di>
<di><dt>content-add</dt><dd>Add one or more new content definitions to the session.</dd></di>
<di><dt>content-modify</dt><dd>Change the directionality of media sending.</dd></di>
<di><dt>content-reject</dt><dd>Reject a content-add action received from another party.</dd></di>
<di><dt>content-remove</dt><dd>Remove one or more content definitions from the session.</dd></di>
<di><dt>description-info</dt><dd>Exchange information about parameters for an application type.</dd></di>
<di><dt>session-accept</dt><dd>Definitively accept a session negotiation.</dd></di>
<di><dt>session-info</dt><dd>Send session-level information, such as a ping or a ringing message.</dd></di>
<di><dt>session-initiate</dt><dd>Request negotiation of a new Jingle session.</dd></di>
<di><dt>session-terminate</dt><dd>End an existing session.</dd></di>
<di><dt>transport-accept</dt><dd>Accept a transport-replace action received from another party.</dd></di>
<di><dt>transport-info</dt><dd>Exchange transport candidates.</dd></di>
<di><dt>transport-reject</dt><dd>Reject a transport-replace action received from another party.</dd></di>
<di><dt>transport-replace</dt><dd>Redefine a transport method or replace it with a different method.</dd></di>
</dl>
</section2>
</section1>
<section1 topic='Session Flow' anchor='session'>
@ -1155,9 +1155,11 @@ PENDING o-----------------------+ |
</section3>
<section3 topic='content-reject' anchor='def-action-content-reject'>
<p>The <strong>content-reject</strong> action is used to reject a content-add action received from another party.</p>
<p>If the content-reject results in zero content definitions for the session, the entity that receives the content-reject SHOULD send a session-terminate action to the other party (since a session with no content definitions is void).</p>
</section3>
<section3 topic='content-remove' anchor='def-action-content-remove'>
<p>The <strong>content-remove</strong> action is used to remove one or more content definitions from the session. The sender MUST specify only the removed content definition(s), not the removed content definition(s) plus the remaining content definition(s). Therefore it is the responsibility of the recipient to maintain a local copy of the current content definition(s). Upon receiving a content-remove from the other party, the recipient MUST NOT send a content-accept and MUST NOT continue to negotiate the transport method or send application data related to that content definition. <note>If the content-remove results in zero content definitions for the session, the entity that receives the content-remove SHOULD send a session-terminate action to the other party (since a session with no content definitions is void).</note></p>
<p>The <strong>content-remove</strong> action is used to remove one or more content definitions from the session. The sender MUST specify only the removed content definition(s), not the removed content definition(s) plus the remaining content definition(s). Therefore it is the responsibility of the recipient to maintain a local copy of the current content definition(s). Upon receiving a content-remove from the other party, the recipient MUST NOT send a content-accept and MUST NOT continue to negotiate the transport method or send application data related to that content definition.</p>
<p>If the content-remove results in zero content definitions for the session, the entity that receives the content-remove SHOULD send a session-terminate action to the other party (since a session with no content definitions is void).</p>
</section3>
<section3 topic='description-info' anchor='def-action-description-info'>
<p>The <strong>description-info</strong> action is used to send informational hints about parameters related to the application type, such as the suggested height and width of a video display area or suggested configuration for an audio stream.</p>
@ -1193,8 +1195,8 @@ PENDING o-----------------------+ |
<p>The <strong>transport-replace</strong> action is used to redefine a transport method, typically for fallback to a different method (e.g., changing from ICE-UDP to Raw UDP for a datagram transport, or changing from &xep0065; to &xep0047; for a streaming transport). If the recipient wishes to use the new transport definition, it MUST send a transport-accept action to the other party; if not, it MUST send a transport-reject action to the other party.</p>
</section3>
<section3 topic='Tie Breaking Related to Jingle Actions' anchor='def-action-ties'>
<p>It is possible that two instances of certain actions can be sent at the same time in the context of an existing session, one by each party; for example, both parties might simulaneously attempt to send a content-add action. In all such cases, the action sent by the initiator MUST overrule the action sent by the responder; i.e., both parties MUST accept the action sent by the initiator and the initiator MUST return an &conflict; error to the responder for the duplicate action, which SHOULD include a Jingle-specific condition of &lt;tie-break/&gt;.</p>
<example caption="Initiator returns unexpected-request error"><![CDATA[
<p>It is possible that two instances of certain actions can be sent at the same time in the context of an existing session, one by each party; for example, both parties might simulaneously attempt to send a content-add action. In all such cases, the action sent by the initiator MUST overrule the action sent by the responder; i.e., both parties MUST accept the action sent by the initiator and the initiator MUST return a &conflict; error to the responder for the duplicate action, which SHOULD include a Jingle-specific condition of &lt;tie-break/&gt;.</p>
<example caption="Initiator returns conflict error on tie-break"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='hb2f164w'
to='juliet@capulet.lit/balcony'
@ -1724,6 +1726,6 @@ PENDING o-----------------------+ |
<p>As a result of feedback received on <cite>XEP-0111</cite>, the original authors of this document (Joe Hildebrand and Peter Saint-Andre) began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team, <note>Google Talk is an instant messaging and voice/video chat service and client provided by Google; see &lt;<link url='http://www.google.com/talk/'>http://www.google.com/talk/</link>&gt;.</note> it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified herein is, therefore, substantially equivalent to the original Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication by the XMPP Standards Foundation.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>The authors would like to thank Rohan Mahy for his valuable input on early versions of the Jingle specifications. Thiago Camargo, Diana Cionoiu, Olivier Cr&#234;te, Dafydd Harries, Antti Ij&#228;s, Tim Julien, Lauri Kaila, Justin Karneges, Jussi Laako, Steffen Larsen, Dirk Meyer, Anthony Minessale, Akito Nozaki, Matt O'Gorman, Mike Ruprecht, Rob Taylor, Matt Tucker, Justin Uberti, Saku Vainio, Unnikrishnan Vikrama Panicker, Brian West, Jeff Williams, and others have also provided helpful input. Thanks also to those who have commented on the &SSIG; and Jingle <note>Before this specification was formally accepted by the XMPP Standards Foundation as an XMPP Extension Protocol, it was discussed on the semi-private &lt;jingle@jabber.org&gt; mailing list. This list has since been resurrected as a special-purpose venue for discussion of Jingle protocols and implementation; interested developers can subscribe and access the archives at at &lt;<link url='http://mail.jabber.org/mailman/listinfo/jingle/'>http://mail.jabber.org/mailman/listinfo/jingle/</link>&gt;.</note> mailing lists.</p>
<p>The authors would like to thank Rohan Mahy for his valuable input on early versions of the Jingle specifications. Thiago Camargo, Diana Cionoiu, Olivier Cr&#234;te, Dafydd Harries, Antti Ij&#228;s, Tim Julien, Lauri Kaila, Justin Karneges, Jussi Laako, Steffen Larsen, Dirk Meyer, Anthony Minessale, Akito Nozaki, Matt O'Gorman, Mike Ruprecht, Rob Taylor, Will Thompson, Matt Tucker, Justin Uberti, Saku Vainio, Unnikrishnan Vikrama Panicker, Brian West, Jeff Williams, and others have also provided helpful input. Thanks also to those who have commented on the &SSIG; and Jingle <note>Before this specification was formally accepted by the XMPP Standards Foundation as an XMPP Extension Protocol, it was discussed on the semi-private &lt;jingle@jabber.org&gt; mailing list. This list has since been resurrected as a special-purpose venue for discussion of Jingle protocols and implementation; interested developers can subscribe and access the archives at at &lt;<link url='http://mail.jabber.org/mailman/listinfo/jingle/'>http://mail.jabber.org/mailman/listinfo/jingle/</link>&gt;.</note> mailing lists.</p>
</section1>
</xep>