<remark><p>Per a vote of the XMPP Council, advanced specification to Draft; XMPP Registrar assigned urn:xmpp:chatneg as associated namespace.</p></remark>
<remark><p>Specified state chart; added optional presence sharing; renamed otr field to logging; harmonized treatment of renegotiation; per XEP-0053, specified use of provisional namespace until spec advances to Draft.</p></remark>
<remark><p>Defined handling of offline requests; specified localization of the title element and all labels; changed syntax of list of unacceptable fields; removed reason field from some examples; added confirmation message to initial negotiation; clarified the initial participating resources; removed id attributes.</p></remark>
<remark><p>Added language field; replaced secure field with security field; changed type of otr, XHTML and Chat State fields from boolean to list-single; added not-acceptable error; several clarifications.</p></remark>
<remark><p>Added continue field and optional terminate acknowledgement; specified renegotiation failure proceedure; added context to Introduction; changed unavailable presence handling; renamed logging field to otr.</p></remark>
<remark><p>Further described contexts in which chat session negotiation could be useful; added more examples; added reference to SIP RFC and explained basic mapping to SIP INVITE method; added XMPP Registrar considerations.</p></remark>
<p>The traditional model for one-to-one chat "sessions" in Jabber/XMPP is for a user to simply send a message to a contact without any formal negotiation of chat session parameters (e.g., see &xmppim;). This informal approach to initiation of a chat session is perfectly acceptable in many contexts, environments, and cultures. However, it may be desirable to formally request the chat and negotiate its parameters before beginning the chat session in some circumstances, such as:</p>
<li>Whenever parameters specific to a chat session must be agreed. e.g., security and privacy parameters (see &xep0116; and &xep0136;).</li>
<li>The parties are unknown to each other, have not exchanged presence, or have not discovered their respective capabilities via &xep0030; or &xep0115;.</li>
<li>When an XMPP-based system interfaces with a SIP-based system built on top of &rfc3261;. <note>In essence, a chat state negotiation request as specified herein is functionally equivalent to a SIP INVITE request, and acceptance of such a request is functionally equivalent to sending a SIP 200 OK response; see Section 17 of <cite>RFC 3261</cite>.</note></li>
<li>Within an organization or culture in which one would not simply begin chatting with another person (e.g., a superior) without first receiving permission to do so.</li>
<p>The following figure attempts to capture the state transitions in visual form.</p>
<code>
o
|
[1]
|
PENDING o---------------+
| |
| [3]
| |
[2]-----[5]------|
| |
[4] |
| |
| |
ACTIVE o |
| |
+------+ |
| | |
| [6] |
| | |
| [7] or [8] |
| | |
+------+ |
| |
+-----[9]-------+
|
o ENDED
</code>
<p>[1] A chat session negotiation is initiated when the user sends a message containing a data form of type "form" with an "accept" field.</p>
<p>[2] A chat session negotiation is accepted when the contact sends a message containing a data form of type "submit" with an "accept" field whose value is "1" or "true".</p>
<p>[3] A chat session negotiation is rejected when the contact sends a message containing a data form of type "submit" with an "accept" field whose value is "0" or "false".</p>
<p>[4] A chat session negotiation is confirmed when the user sends a message containing a data form of type "result" with an "accept" field whose value is "1" or "true".</p>
<p>[5] A chat session negotiation is confirmed when the user sends a message containing a data form of type "result" with an "accept" field whose value is "0" or "false".</p>
<p>[6] An existing chat session is re-negotiated when either party sends a message containing a data form of type "form" with a "renegotiate" field whose value is "1" or "true".</p>
<p>[7] A chat session re-negotiation is accepted when the other party sends a message containing a data form of type "submit" with a "renegotiate" field whose value is "1" or "true".</p>
<p>[8] A chat session re-negotiation is rejected when the other party sends a message containing a data form of type "submit" with a "renegotiate" field whose value is "0" or "false"; however, the session remains in the active state with the previously-negotiated parameters in force.</p>
<p>[9] 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".</p>
<p>In order to initiate a negotiated chat session, the initiating party ("user") sends a &MESSAGE;<note>The &MESSAGE; stanza is used because the user does not necessarily know which of the contact's resources is most available (or indeed if the contact is online).</note> stanza to the receiving party ("contact") containing a <feature/> child qualified by the 'http://jabber.org/protocol/feature-neg' namespace. The &MESSAGE; stanza MUST NOT contain a &BODY; child element (as specified in &rfc3921;). The &MESSAGE; stanza type SHOULD be "normal" (either explicitly or by non-inclusion of the 'type' attribute). The stanza MUST contain a &THREAD; element for tracking purposes (where the newly-generated ThreadID is unique to the proposed session). The data form MUST contain a hidden FORM_TYPE field whose value is "urn:xmpp:chatneg" and MUST contain a boolean field named "accept". &BOOLEANNOTE; The inclusion of "logging", "disclosure" and "security" fields is also RECOMMENDED. Note: The options within any 'list-single' fields SHOULD appear in order of preference.</p>
<p>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 <em>immediate</em> 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.</p>
<p>In the following example of a negotiation request, Romeo requests a chat with Juliet and also queries her regarding whether she is able to disallow all message logging (see &xep0136;) <note>A client MUST NOT set the 'logging' field to 'mustnot' unless it has confirmed that its server will allow it to switch off Automated Archiving (see <cite>Message Archiving</cite>).</note>, whether she wants to temporarily share presence for this session (see the <linkurl='#impl-presence'>Sharing Presence</link> section of this document), and whether she wants to support the &xep0071; and &xep0085; extensions during this chat session. He asks Juliet's client if it is prepared to make a (legally binding) guarantee that it does not intentionally implement any feature (not even a disabled feature) that might disclose the content of the chat, any associated (decryption) keys, or his identity to any third-party (see <cite>Encrypted Session Negotiation</cite>). He also requires that they are both connected securely to their servers, and asks which language she prefers amongst those he can write. (Note: These fields are examples only; a full set of chat session negotiation parameters will be registered as described in the <linkurl='#registrar'>XMPP Registrar Considerations</link> section of this document.)</p>
<p>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 <cite>Advanced Message Processing</cite> rule included in the request specifies otherwise) then the server MAY store the request for later delivery.</p>
<p>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 <em>immediate</em> 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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 <linkurl='#secure-leak'>Presence Leaks</link>). 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.</p>
<p>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:</p>
<p>If the contact's client does not support feature negotiation or does not support the "urn:xmpp:chatneg" FORM_TYPE, it SHOULD return a &unavailable; error:</p>
<p>If the contact's client does not support one or more of the <em>required</em> features, it SHOULD return a &feature; error, specifying the field(s) not implemented using the 'var' attribute of one or more <field/> child elements of a <feature/> child element of the <error/> scoped by the 'http://jabber.org/protocol/feature-neg' namespace:</p>
<p>If the contact's client supports <em>none</em> of the options for one or more <em>required</em> fields, it SHOULD return a ¬acceptable; error, specifying the field(s) with unsupported options using the 'var' attribute of one or more <field/> child elements of a <feature/> child element of the <error/> scoped by the 'http://jabber.org/protocol/feature-neg' namespace:</p>
<p>If the contact accepted the chat (see <linkurl='#new-accept'>Accepting a Chat Session</link>) 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. <note>See <cite>Encrypted Session Negotiation</cite> for example of other instances where the user might find the values submitted by the contact unacceptable.</note> In any case the user's client SHOULD verify that the selected values are acceptable before completing the session negotiation -- and confirming that the chat session is open -- by replying with a form with the form 'type' attribute set to 'result'. The form MUST contain the FORM_TYPE field and the "accept" field set to "1" or "true". The user MAY include other content (e.g., a &BODY; element) in the confirmation stanza:</p>
<p>Alternatively, if the user decides to cancel the session negotiation then the client MUST reply with a data form containing the FORM_TYPE field and the "accept" field set to "0" or "false":</p>
<section1topic='Moving A Chat Session to a Different Resource'anchor='move'>
<p>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:</p>
<examplecaption="One party asks to switch session to another of its resources"><