moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

0.26

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1879 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-05-28 21:09:22 +00:00
parent a82925089c
commit 61ccc7452a
1 changed files with 11 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
xep-0166.xml
View File

@ -10,7 +10,7 @@
<abstract>This specification defines an XMPP protocol extension for initiating and managing peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards. The protocol provides a pluggable model that enables the core session management semantics to be used for a wide variety of application types (e.g., voice chat, video chat, file sharing) and with a wide variety of transport methods (e.g., TCP, UDP, ICE, application-specific transports).</abstract>
&LEGALNOTICE;
<number>0166</number>
<status>Proposed</status>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@ -19,13 +19,19 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>TO BE ASSIGNED</shortname>
<shortname>NOT_YET_ASSIGNED</shortname>
&scottlu;
&joebeda;
&stpeter;
&robmcqueen;
&seanegan;
&hildjj;
<revision>
<version>0.26</version>
<date>2008-05-28</date>
<initials>psa</initials>
<remark><p>Corrected several errors in the state diagrams.</p></remark>
</revision>
<revision>
<version>0.25</version>
<date>2008-02-29</date>
@ -411,7 +417,6 @@ Romeo Juliet
| +-----------------------+
|/ |
PENDING o---------------------+ |
| | content-accept, | |
| | content-modify, | |
| | content-remove, | |
| | session-info, | |
@ -450,7 +455,7 @@ PENDING o---------------------+ |
</tr>
<tr>
<td>content-accept</td>
<td>Accept the content type of a session-initiate action, or accept a content-add or content-replace action received from another party.</td>
<td>Accept a content-add or content-replace action received from another party. This action MUST NOT be sent while the session is in the PENDING state.</td>
</tr>
<tr>
<td>content-add</td>
@ -466,7 +471,7 @@ PENDING o---------------------+ |
</tr>
<tr>
<td>content-replace</td>
<td>Replace the definition of a content type with a new definition. The application type MUST NOT change but the definition of the application type MAY be modified (e.g., a file offer may be modified to a file request). The transport method MAY be changed (e.g., from &xep0065; to &xep0047;) or the definition of the existing method MAY be modified. The sender MUST specify only the replaced content-type(s), not any existing content-type that has not been replaced. Therefore it is the responsibility of the recipient to maintain a local copy of the current content type definition. This action MUST NOT be sent while the session is in the PENDING state. When a party sends a content-replace, it MUST ignore any actions received from the other party until it receives acknowledgement of the content-replace. If the recipient wishes to include the replaced content type in the session, it MUST send a content-accept action to the other party. <note>If both parties send content-replace actions at the same time, the content-replace from the session initiator MUST trump the content-replace from the recipient and the initiator SHOULD return an &unexpected; error to the other party.</note></td>
<td>Replace the definition of a content type with a new definition; essentially this functions as a simultaneous content-remove and content-add. The application type MUST NOT change but the definition of the application type MAY be modified (e.g., a file offer may be modified to a file request). The transport method MAY be changed (e.g., from &xep0065; to &xep0047;) or the definition of the existing method MAY be modified. The sender MUST specify only the replaced content-type(s), not any existing content-type that has not been replaced. Therefore it is the responsibility of the recipient to maintain a local copy of the current content type definition. This action MUST NOT be sent while the session is in the PENDING state. When a party sends a content-replace, it MUST ignore any actions received from the other party until it receives acknowledgement of the content-replace. If the recipient wishes to include the replaced content type in the session, it MUST send a content-accept action to the other party. <note>If both parties send content-replace actions at the same time, the content-replace from the session initiator MUST trump the content-replace from the recipient and the initiator SHOULD return an &unexpected; error to the other party.</note></td>
</tr>
<tr>
<td>session-accept</td>
@ -1141,6 +1146,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 &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 this document. Thiago Camargo, Dafydd Harries, Antti Ij&#228;s, Lauri Kaila, Justin Karneges, Jussi Laako, Anthony Minessale, Matt O'Gorman, Rob Taylor, Matt Tucker, Saku Vainio, Brian West, and others have also provided helpful input. Thanks also to those who have commented on the &SSIG; and (earlier) 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; although that list is no longer used since the standards@xmpp.org list is the preferred discussion venue, for historical purposes it is publicly archived at &lt;<link url='http://mail.jabber.org/pipermail/jingle/'>http://mail.jabber.org/pipermail/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, Anthony Minessale, Matt O'Gorman, Rob Taylor, Matt Tucker, Saku Vainio, Brian West, and others have also provided helpful input. Thanks also to those who have commented on the &SSIG; and (earlier) 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; although that list is no longer used since the standards@xmpp.org list is the preferred discussion venue, for historical purposes it is publicly archived at &lt;<link url='http://mail.jabber.org/pipermail/jingle/'>http://mail.jabber.org/pipermail/jingle/</link>&gt;.</note> mailing lists.</p>
</section1>
</xep>