diff --git a/xep-0166.xml b/xep-0166.xml index 4082a5b6..771581d0 100644 --- a/xep-0166.xml +++ b/xep-0166.xml @@ -10,7 +10,7 @@ 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). &LEGALNOTICE; 0166 - Proposed + Experimental Standards Track Standards Council @@ -19,13 +19,19 @@ - TO BE ASSIGNED + NOT_YET_ASSIGNED &scottlu; &joebeda; &stpeter; &robmcqueen; &seanegan; &hildjj; + + 0.26 + 2008-05-28 + psa +

Corrected several errors in the state diagrams.

 + 0.25 2008-02-29 @@ -411,7 +417,6 @@ Romeo Juliet | +-----------------------+ |/ | PENDING o---------------------+ | - | | content-accept, | | | | content-modify, | | | | content-remove, | | | | session-info, | | @@ -450,7 +455,7 @@ PENDING o---------------------+ | content-accept - Accept the content type of a session-initiate action, or accept a content-add or content-replace action received from another party. + 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. content-add @@ -466,7 +471,7 @@ PENDING o---------------------+ | content-replace - 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. 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. + 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. 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. session-accept @@ -1141,6 +1146,6 @@ PENDING o---------------------+ |

As a result of feedback received on XEP-0111, 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, Google Talk is a messaging and voice chat service and client provided by Google; see <http://www.google.com/talk/>. 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.

-

The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Thiago Camargo, Dafydd Harries, Antti Ijä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 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; 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 <http://mail.jabber.org/pipermail/jingle/>. mailing lists.

+

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, 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 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; 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 <http://mail.jabber.org/pipermail/jingle/>. mailing lists.