Specified state chart; added optional presence sharing; harmonized treatment of renegotiation; changed otr, xhtml-im, and chatstates fields back to boolean; per XEP-0053, specified use of provisional namespace until spec advances to Draft.
Specified state chart; added optional presence sharing; harmonized treatment of renegotiation; per XEP-0053, specified use of provisional namespace until spec advances to Draft.
This proposal defines best practices for such a negotiation, re-using the protocol defined in &xep0020;.
+The specification addresses the following use cases:
+The following figure attempts to capture the state transitions in visual form.
@@ -166,7 +175,7 @@ PENDING o---------------+
[8] A chat session is terminated when either party sends a message containing a data form of type "submit" with a "terminate" field whose value is "1" or "true".
In order to initiate a negotiated chat session, the initiating party ("user") sends a &MESSAGE;
Note: Chat sessions may be conducted between entities who are never online at the same time. However, if the user is interested only in an immediate chat session then the user SHOULD instruct the contact's server not to store the message for later delivery (see &xep0160;) using the &xep0079; protocol.
In the following example of a negotiation request, Romeo requests a chat with Juliet and also queries her regarding whether she wants to enable all message logging (see &xep0136;)
The user MAY request a session with a specific resource of the contact. However, if the user specifies no resource (or if the specified resource is not available), then the contact's server delivers the request to the contact's most available resource (which in the examples below happens to be "balcony"). If no resource is available (and no Advanced Message Processing rule included in the request specifies otherwise) then the server MAY store the request for later delivery.
If, upon reception of a user's chat session request, a contact finds that the request had been stored for later delivery, and if the contact is interested only in an immediate chat session, then it SHOULD initiate a new chat session negotiation (including a newly-generated ThreadID) instead of responding to the user's request. Note: Sending any response to the user's original request would leak presence information since it would divulge the fact that the contact had been offline rather than just ignoring the user.
In any response to the user's request, the contact's client MUST mirror the &THREAD; value so that the user's client can correctly track the response.
If the request is accepted then the contact's client MUST include in its response values for all the fields that the request indicated are required. If the contact's client does not support one of the default values or if the contact has disabled its support (as for Chat State Notifications and XHTML formatting in the example below), and the client can still accept the request, then it MUST set that field to a value that it can support.
@@ -286,7 +295,7 @@ PENDING o---------------+ ]]>Note: Both entities MUST assume the session is being established with the resource of the contact that sends the reply, even if the user sent its request to a different resource of the contact.
If the contact does not want to reveal presence to the user for whatever reason then the contact's client SHOULD return no response or error (see Presence Leaks). Also, if the contact is using a legacy client then it MAY not support returning any response or error. In both these cases the user MAY proceed to send stanzas to the contact outside the context of a negotiated chat session.
However, if the contact simply prefers not to chat then the client SHOULD decline the invitation. The data form MUST contain the FORM_TYPE field and the "accept" field set to "0" or "false". It is RECOMMENDED that the form does not contain any other fields even if the request indicated they are required. The client MAY include a reason in the &BODY; child of the &MESSAGE; stanza:
If the contact accepted the chat (see Accepting a Chat) then the user MUST either complete or cancel the session negotiation. If the contact chose an option other than the default (prefered) value for one or more of the fields, then instead of having the client accept the session automatically the user may prefer to review the values that the contact selected before confirming that the session is open.
If the contact accepted the chat (see Accepting a Chat Session) then the user MUST either complete or cancel the session negotiation. If the contact chose an option other than the default (prefered) value for one or more of the fields, then instead of having the client accept the session automatically the user may prefer to review the values that the contact selected before confirming that the session is open.
Either party MAY ask to continue the session using another of its resources. The requesting party does this by submitting a form with a "continue" field containing the value of the new resource:
-Either party MAY ask to continue the session using another of its resources. The requesting party does this by submitting a form with a "continue" field containing the value of the new resource:
+The requesting party SHOULD NOT send stanzas within the session from either resource until the other party has accepted the switch to the new resource.
-The other client SHOULD accept the switch automatically since the requesting party might otherwise be unable to continue the session:
-The requesting party SHOULD NOT send stanzas within the session from either resource until the other party has accepted the switch to the new resource.
+The other client SHOULD accept the switch automatically since the requesting party might otherwise be unable to continue the session:
+Once the other party has accepted the switch then all stanzas sent within the chat session MUST be to or from the new resource. Note: Both parties MUST ensure that they comply with all the other chat session negotiation parameters that were previously agreed for this session.
-At any time during an existing chat session, either party MAY attempt to renegotiate the parameters of the session using the protocol described in Negotiating a New Chat Session. The requesting party does this by sending a new &MESSAGE; stanza containing a feature negotiation form and a &THREAD; element with the same value as that of the existing chat session. Note: The "accept" field MUST NOT be included in a renegotiation form. The other fields MAY be different from the set of fields included in the initial session negotiation form.
-Once the other party has accepted the switch then all stanzas sent within the chat session MUST be to or from the new resource. Note: Both parties MUST ensure that they comply with all the other chat session negotiation parameters that were previously agreed for this session.
+At any time during an existing chat session, either party MAY attempt to renegotiate the parameters of the session using the protocol described in Negotiating a New Chat Session. The requesting party does this by sending a new &MESSAGE; stanza containing a feature negotiation form and a &THREAD; element with the same value as that of the existing chat session. Note: The "accept" field MUST NOT be included in a renegotiation form. The other fields MAY be different from the set of fields included in the initial session negotiation form.
+The requesting party MAY continue to send stanzas within the session while it is waiting for the other party to either accept the parameters or report an error.
-In order to reject the renegotiation, the other party shall send a message containing a data form of type "submit" with the 'renegotiate' field set to a value of "1" or "true".
-The requesting party MAY continue to send stanzas within the session while it is waiting for the other party to either accept the parameters or report an error.
+In order to reject the renegotiation, the other party shall send a message containing a data form of type "submit" with the 'renegotiate' field set to a value of "1" or "true".
+Note: Both parties MUST consider the renegotiation to be complete as soon as the parameter acceptance message has been sent (or received).
-Note: The requesting party SHOULD NOT send a renegotiation completion or cancelation message (see Completing or Canceling the Negotiation).
-Note: Both parties MUST ensure that they continue to comply with all the chat session negotiation parameters that were not renegotiated but had previously been agreed for this session.
-In order to reject the renegotiation, the other party shall send a message containing a data form of type "submit" with the 'renegotiate' field set to a value of "0" or "false".
-Note: Both parties MUST consider the renegotiation to be complete as soon as the parameter acceptance message has been sent (or received).
+Note: The requesting party SHOULD NOT send a renegotiation completion or cancelation message (see Completing or Canceling the Negotiation).
+Note: Both parties MUST ensure that they continue to comply with all the chat session negotiation parameters that were not renegotiated but had previously been agreed for this session.
+In order to reject the renegotiation, the other party shall send a message containing a data form of type "submit" with the 'renegotiate' field set to a value of "0" or "false".
+If the other party's client does not support one or more of the required features, it SHOULD return a &feature; error. If the other party's client supports none of the options for one or more required fields, it SHOULD return a ¬acceptable; error (see Rejecting a Chat). Note: In any of these cases the existing negotiated chat session parameters are maintained. Either party MAY choose to terminate the chat session only as specified in the section Terminating a Chat.
- -In order to explicitly terminate a negotiated chat, the party that wishes to end the chat MUST do so by sending a &MESSAGE; containing a data form of type "submit". The &MESSAGE; stanza MUST contain a &THREAD; element with the same XML character data as the original initiation request. The data form containing a boolean field named "terminate" set to a value of "1" or "true".
-If the other party's client does not support one or more of the required features, it SHOULD return a &feature; error. If the other party's client supports none of the options for one or more required fields, it SHOULD return a ¬acceptable; error (see Rejecting a Chat Session). Note: In any of these cases the existing negotiated chat session parameters are maintained. Either party MAY choose to terminate the chat session only as specified in the section Terminating a Chat Session.
+In order to explicitly terminate a negotiated chat, the party that wishes to end the chat MUST do so by sending a &MESSAGE; containing a data form of type "submit". The &MESSAGE; stanza MUST contain a &THREAD; element with the same XML character data as the original initiation request. The data form containing a boolean field named "terminate" set to a value of "1" or "true".
+Both parties MUST then consider the chat session to be ended.
-The other party's client MAY explicitly acknowledge the termination of the chat by sending a &MESSAGE; containing a data form of type "result", and the value of the "terminate" field set to "1" or "true" (see Encrypted Session Negotiation for a practical example). The client MUST mirror the &THREAD; value it received.
-Both parties MUST then consider the chat session to be ended.
+The other party's client MAY explicitly acknowledge the termination of the chat by sending a &MESSAGE; containing a data form of type "result", and the value of the "terminate" field set to "1" or "true" (see Encrypted Session Negotiation for a practical example). The client MUST mirror the &THREAD; value it received.
+If a party receives an XMPP presence stanza of type "unavailable" from the full JID (&FULLJID;) of the other party (i.e., the resource with which it has had an active session) during a chat session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated chat until it reconnects and receives "offline" messages).
-However, the receiving party MAY assume that the other client will not be able to continue the session.
However, the receiving party MAY assume that the other client will not be able to continue the session.
When mapping instant messaging flows to SIP, implementations SHOULD adhere to &xmppsimple;.
@@ -636,7 +643,7 @@ PENDING o---------------+