From 364d8530e8940670dd776a703fa18790dc9df9cc Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 11 Jan 2008 22:42:55 +0000 Subject: [PATCH] 0.23 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1570 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0166.xml | 47 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 33 insertions(+), 14 deletions(-) diff --git a/xep-0166.xml b/xep-0166.xml index b53ca3de..0043f162 100644 --- a/xep-0166.xml +++ b/xep-0166.xml @@ -26,6 +26,12 @@ &robmcqueen; &seanegan; &hildjj; + + 0.23 + 2008-01-11 + psa +

Removed content-accept after content-remove; removed errors for unsupported-content and unsupported-transports since they are handled via session-terminate; clarified handling of responder attribute.

 + 0.22 2007-12-06 @@ -460,7 +466,7 @@ PENDING o---------------------+ | content-accept - Accept a content-add, content-modify, or content-remove action received from another party. + Accept a content-add or content-modify action received from another party. content-add @@ -472,7 +478,7 @@ PENDING o---------------------+ | content-remove - Remove one or more content types from the session. The sender MUST specify only the removed content-type(s), not the removed content-type(s) plus the remaining content-type(s). Therefore it is the responsibility of the recipient to maintain a local copy of the current content type definition. A client MUST NOT return an error upon receipt of a 'content-remove' action for a content type that is received after a 'content-remove' action has been sent but before the action has been acknowledged by the peer. If the content-remove results in zero content types 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 types is void). + Remove one or more content types from the session. The sender MUST specify only the removed content-type(s), not the removed content-type(s) plus the remaining content-type(s). Therefore it is the responsibility of the recipient to maintain a local copy of the current content type definition. The recipient SHOULD NOT send a content-accept with the new content type definition after receiving a content-remove. A client MUST NOT return an error upon receipt of a 'content-remove' action for a content type that is received after a 'content-remove' action has been sent but before the action has been acknowledged by the peer. If the content-remove results in zero content types 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 types is void). session-accept @@ -506,6 +512,17 @@ PENDING o---------------------+ |

Once the initiator has discovered which of the responder's XMPP resources is ideal for the desired application format, it sends a session initiation request to the responder. This request is an IQ-set containing a &JINGLE; element qualified by the 'http://www.xmpp.org/extensions/xep-0166.html#ns' namespace &NSNOTE;, where the value of the 'action' attribute is "session-initiate" and where the &JINGLE; element contains one or more &CONTENT; elements. Each &CONTENT; element defines a content type to be transferred during the session, and each &CONTENT; element in turn contains one &DESCRIPTION; child element that specifies a desired application format and one &TRANSPORT; child element that specifies a potential transport method. If either party wishes to propose the use of multiple transport methods for the same application format, it must send multiple &CONTENT; elements.

Note: The syntax and semantics of the &DESCRIPTION; and &TRANSPORT; elements are out of scope for this specification, since they are defined in related specifications. The syntax and semantics of the &JINGLE; and &CONTENT; elements are specified in this document under Formal Definition.

Note: In order to expedite session establishment, the initiator MAY send transport candidates (e.g., for negotiation of the ICE transport) immediately after sending the "session-initiate" message and before receiving acknowledgement from the responder (i.e., the initiator MUST consider the session to be PENDING even before receiving acknowledgement). Given in-order delivery, the responder should receive such "transport-info" messages after receiving the "session-initiate" message (if not, it is appropriate for the responder to return <unknown-session/> errors since according to its state machine the session does not exist).

+ + + + + + + ]]> @@ -599,7 +616,7 @@ PENDING o---------------------+ |

If (after negotiation of transport methods and application formats as well as checking of transport candidates) the responder determines that it will be able to establish a connection, it sends a definitive acceptance to the initiator.

-

Note: In the accept stanza, the &JINGLE; element MUST contain one or more <content/> elements, each of which MUST contain one <description/> element and one <transport/> element. The &JINGLE; element SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity, and the initiator SHOULD send all future commmunications about this Jingle session to the JID provided in the 'responder' attribute.

+

Note: In the session-accept stanza, the &JINGLE; element MUST contain one or more <content/> elements, each of which MUST contain one <description/> element and one <transport/> element. The &JINGLE; element SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity; after sending acknowledgement of the session-accept, the initiator SHOULD send all future commmunications about this Jingle session to the JID provided in the 'responder' attribute and note the new JID in the user interface.

The initiator then acknowledges the responder's definitive acceptance, after which the parties can exchange media over the negotiated connection.

If one of the parties cannot find a suitable transport method or candidate, it SHOULD terminate the session as described below.

 @@ -674,6 +691,17 @@ PENDING o---------------------+ |

At any point after initiation of a Jingle session, either entity MAY send an informational message to the other party, for example to change a transport method, inform the other party that a device is ringing or that a scheduled event has occurred or will occur, etc.

An informational message MUST be an IQ-set containing a &JINGLE; element whose 'action' attribute is set to a value of "session-info" or "transport-info"; the &JINGLE; element MUST further contain a payload child element (specific to the session or to a transport method) that specifies the information being communicated. If the party that receives an informational message does not understand the payload, it MUST return a &feature; error with a Jingle-specific error condition of <unsupported-info/>.

+ + + + + + + ]]>

If either party receives an empty "session-info" message for an active session, it MUST send an empty IQ result; this way, an empty "session-info" message may be used as a "ping" to determine session vitality.

Informational messages are specific to a particular application type or transport method and therefore are described in specifications other than this one.

 @@ -755,7 +783,7 @@ PENDING o---------------------+ |

The Jingle-specific error conditions are as follows. These condition elements are qualified by the 'http://www.xmpp.org/extensions/xep-0166.html#ns-errors' namespace &NSNOTE;.

- +
@@ -771,21 +799,11 @@ PENDING o---------------------+ | - - - - - - - - - -
Jingle Condition XMPP Condition&badrequest; The 'sid' attribute specifies a session that is unknown to the recipient (e.g., no longer live according to the recipient's state machine because the recipient previously terminated the session).
<unsupported-content/>¬acceptable;The recipient does not support any of the desired application formats.
<unsupported-info/> &feature; The recipient does not support the informational payload of a session-info message.
<unsupported-transports/>¬acceptable;The recipient does not support any of the desired transport methods.
 @@ -1039,6 +1057,7 @@ PENDING o---------------------+ | +