mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 18:22:24 -05:00
0.32: content-reject and transport-reject actions
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2344 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
a2605dae08
commit
736bb5c9e6
30
xep-0166.xml
30
xep-0166.xml
@ -26,6 +26,12 @@
|
||||
&robmcqueen;
|
||||
&seanegan;
|
||||
&hildjj;
|
||||
<revision>
|
||||
<version>0.32</version>
|
||||
<date>2008-10-07</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Added content-reject action to mirror content-accept for replies to content-add; also added transport-reject action to mirror transport-accept for replies to transport-replace.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.31</version>
|
||||
<date>2008-09-25</date>
|
||||
@ -507,10 +513,12 @@ PENDING o----------------------+ |
|
||||
| | content-accept, | |
|
||||
| | content-add, | |
|
||||
| | content-modify, | |
|
||||
| | content-reject, | |
|
||||
| | content-remove, | |
|
||||
| | session-info, | |
|
||||
| | transport-accept, | |
|
||||
| | transport-info, | |
|
||||
| | transport-reject, | |
|
||||
| | transport-replace | |
|
||||
| +-------------------+ |
|
||||
| |
|
||||
@ -520,10 +528,12 @@ PENDING o----------------------+ |
|
||||
| | content-accept, | |
|
||||
| | content-add, | |
|
||||
| | content-modify, | |
|
||||
| | content-reject, | |
|
||||
| | content-remove, | |
|
||||
| | session-info, | |
|
||||
| | transport-accept, | |
|
||||
| | transport-info, | |
|
||||
| | transport-reject, | |
|
||||
| | transport-replace | |
|
||||
| +-------------------+ |
|
||||
| |
|
||||
@ -544,6 +554,7 @@ PENDING o----------------------+ |
|
||||
<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>session-accept -- Definitively accept a session negotiation.</li>
|
||||
<li>session-info -- Send session-level information, such as a ringing message.</li>
|
||||
@ -551,6 +562,7 @@ PENDING o----------------------+ |
|
||||
<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>
|
||||
</section2>
|
||||
@ -916,11 +928,14 @@ PENDING o----------------------+ |
|
||||
<p>The <strong>content-accept</strong> action is used to accept a content-add action received from another party.</p>
|
||||
</section3>
|
||||
<section3 topic='content-add' anchor='def-action-content-add'>
|
||||
<p>The <strong>content-add</strong> action is used to add one or more new content definitions to the session. The sender MUST specify only the added content definition(s), not the added content definition(s) plus the existing content definition(s). Therefore it is the responsibility of the recipient to maintain a local copy of the current content definition(s). If the recipient wishes to include the new content definition in the session, it MUST send a content-accept action to the other party.</p>
|
||||
<p>The <strong>content-add</strong> action is used to add one or more new content definitions to the session. The sender MUST specify only the added content definition(s), not the added content definition(s) plus the existing content definition(s). Therefore it is the responsibility of the recipient to maintain a local copy of the current content definition(s). If the recipient wishes to include the new content definition in the session, it MUST send a content-accept action to the other party; if not, it MUST send a content-reject action to the other party.</p>
|
||||
</section3>
|
||||
<section3 topic='content-modify' anchor='def-action-content-modify'>
|
||||
<p>The <strong>content-modify</strong> action is used to change the direction of an existing content definition thorugh modification of the 'senders' attribute. If the recipient deems the directionality of a content-modify action to be unacceptable, it MAY reply with a contrary content-modify action, terminate the session, or simply refuse to send or accept application data in the new direction. In any case, the recipient MUST NOT send a content-accept action in response to the content-modify.</p>
|
||||
</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>
|
||||
</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 related to that content definition 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>
|
||||
</section3>
|
||||
@ -942,8 +957,11 @@ PENDING o----------------------+ |
|
||||
<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>
|
||||
</section3>
|
||||
<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>
|
||||
</section3>
|
||||
<section3 topic='transport-replace' anchor='def-action-transport-replace'>
|
||||
<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).</p>
|
||||
<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, content-modify, or content-remove 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 &unexpected; error to the responder for the duplicate action.</p>
|
||||
@ -1180,15 +1198,15 @@ PENDING o----------------------+ |
|
||||
<xs:element name='jingle'>
|
||||
<xs:complexType>
|
||||
<xs:sequence>
|
||||
<xs:element ref='content'
|
||||
<xs:element name='content'
|
||||
type='contentElementType'
|
||||
minOccurs='0'
|
||||
maxOccurs='unbounded'/>
|
||||
<xs:element ref='reason'
|
||||
<xs:element name='reason'
|
||||
type='reasonElementType'
|
||||
minOccurs='0'
|
||||
maxOccurs='1'/>
|
||||
<xs:element ref='thread'
|
||||
<xs:element name='thread'
|
||||
type='threadElementType'
|
||||
minOccurs='0'
|
||||
maxOccurs='1'/>
|
||||
@ -1336,6 +1354,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 a messaging and voice chat service and client provided by Google; see <<link url='http://www.google.com/talk/'>http://www.google.com/talk/</link>>.</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ête, Dafydd Harries, Antti Ijäs, Tim Julien, Lauri Kaila, Justin Karneges, Jussi Laako, Steffen Larsen, Anthony Minessale, Akito Nozaki, Matt O'Gorman, Rob Taylor, Matt Tucker, Justin Uberti, Saku Vainio, 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 <jingle@jabber.org> 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 <<link url='http://mail.jabber.org/mailman/listinfo/jingle/'>http://mail.jabber.org/mailman/listinfo/jingle/</link>>.</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ête, Dafydd Harries, Antti Ijäs, Tim Julien, Lauri Kaila, Justin Karneges, Jussi Laako, Steffen Larsen, Anthony Minessale, Akito Nozaki, Matt O'Gorman, Mike Ruprecht, Rob Taylor, Matt Tucker, Justin Uberti, Saku Vainio, 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 <jingle@jabber.org> 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 <<link url='http://mail.jabber.org/mailman/listinfo/jingle/'>http://mail.jabber.org/mailman/listinfo/jingle/</link>>.</note> mailing lists.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user