From 3dced7080a95541520121884074257e2697d7f85 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Sat, 18 Apr 2009 21:47:00 +0000 Subject: [PATCH] minor corrections and clarifications git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3056 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0166.xml | 42 ++++++++++++++++++++++-------------------- 1 file changed, 22 insertions(+), 20 deletions(-) diff --git a/xep-0166.xml b/xep-0166.xml index 40ca9e7d..1503a6ab 100644 --- a/xep-0166.xml +++ b/xep-0166.xml @@ -678,22 +678,22 @@ PENDING o-----------------------+ |

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 Security Considerations section of this document regarding information exposure when the responder sends transport candidates to the initiator.

The actions related to management of the overall Jingle session are as follows (detailed definitions are provided in the Action Attribute section of this document).

- +
+
content-accept
Accept a content-add action received from another party.
 +
content-add
Add one or more new content definitions to the session.
 +
content-modify
Change the directionality of media sending.
 +
content-reject
Reject a content-add action received from another party.
 +
content-remove
Remove one or more content definitions from the session.
 +
description-info
Exchange information about parameters for an application type.
 +
session-accept
Definitively accept a session negotiation.
 +
session-info
Send session-level information, such as a ping or a ringing message.
 +
session-initiate
Request negotiation of a new Jingle session.
 +
session-terminate
End an existing session.
 +
transport-accept
Accept a transport-replace action received from another party.
 +
transport-info
Exchange transport candidates.
 +
transport-reject
Reject a transport-replace action received from another party.
 +
transport-replace
Redefine a transport method or replace it with a different method.
 +
@@ -1155,9 +1155,11 @@ PENDING o-----------------------+ |

The content-reject action is used to reject a content-add action received from another party.

+

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).

 -

The content-remove 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. 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).

+

The content-remove 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.

+

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).

The description-info 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.

@@ -1193,8 +1195,8 @@ PENDING o-----------------------+ |

The transport-replace 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.

 -

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 <tie-break/>.

- 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 <tie-break/>.

+ 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 an instant messaging and voice/video 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 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, 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 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 <http://mail.jabber.org/mailman/listinfo/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, 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 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 <http://mail.jabber.org/mailman/listinfo/jingle/>. mailing lists.