<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>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 MAY include an 'id' attribute and 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 "http://jabber.org/protocol/chatneg" and MUST contain a boolean field named "accept". &BOOLEANNOTE; The inclusion of "otr" and "security" fields is also RECOMMENDED. Note: The options within any 'list-single' fields SHOULD appear in order of preference.</p>
<p>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;) <note>A client MUST NOT set the 'otr' field to 'true' unless it has confirmed that its server will allow it to switch off Automated Archiving (see <cite>Message Archiving</cite>).</note> and support the &xep0071; and &xep0085; extensions during this chat session. He also requires that they are both connected securely to their servers, and asks which language she prefers amoungst 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 contact's server delivers the request to the contact's most available resource (which in the examples below happens to be "balcony").</p>
<p>In any response to the request, the contact's client MUST mirror any 'id' attribute and &THREAD; value so that the user's client can correctly track the response.</p>
<p>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>In the example below we assume that Juliet accepts the chat and specifies that she prefers to speak Italian with Romeo:</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='#security'>Security Considerations</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:</p>
<p>If the contact's client does not support feature negotiation or does not support the "http://jabber.org/protocol/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 and SHOULD specify the field(s) not implemented in a comma-separated list in the XMPP <text/> element:</p>
<p>If the contact's client supports <em>none</em> of the options for one or more fields, it SHOULD return a ¬acceptable; error and SHOULD specify the field(s) with unsupported options in a comma-separated list in the XMPP <text/> element:</p>
<examplecaption="Contact returns options not acceptable error"><