In order to initiate a negotiated chat session, the initiating party ("user") sends a &MESSAGE; 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 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). The &MESSAGE; stanza type SHOULD be "normal" (either explicitly or by non-inclusion of the 'type' attribute). The stanza SHOULD 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 following is an example of a negotiation request:

In the foregoing example, Romeo requests a chat with Juliet and also queries her regarding whether she wants to disable all message logging (see &xep0136;) 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 Message Archiving). and support &xep0071; and &xep0085; extensions during this chat session. (Note: These fields are examples only; a full set of chat session negotiation parameters will be registered as described in the XMPP Registrar Considerations section of this document.)

Juliet's server delivers Romeo's request to her most available resource (which happens to be "balcony").

In any response to the request, the contact's client MUST mirror the 'id' attribute and &THREAD;value so that the user's client can correctly track the response.

We assume that Juliet accepts the chat and specifies that she does not want to log messages or use XHTML formatting but that she does want to use Chat State Notifications:

However, it could be that Juliet is busy so she declines the invitation.

If Juliet'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. However, if Juliet does not want to reveal her presence to Romeo for whatever reason, or she is using a legacy client that does not support returning a &unavailable; error, then her client MAY return no error. In this case Romeo MAY, proceed to send stanzas to Juliet outside the context of a negotiated chat session.

If Juliet's client does not support one of the required features, it SHOULD return a &feature; error (but MAY return no error if, for example, Juliet does not want to reveal her presence to Romeo for whatever reason):

If Juliet's client does not support one of the optional features (e.g., Chat State Notifications) but it accepts the request, it MUST set the value of that boolean variable to "0" or "false".

At any time during an existing chat session, either party MAY attempt to renegotiate the parameters of the 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 SHOULD NOT be included in a renegotiation form. The set of other fields in the form MAY be different from the set included in the initial session negotitation.

If the other party's client does not support one of the required features, it SHOULD return a &feature; error instead. In that case the existing negotiated chat session parameters are maintained. Either party MAY then terminate the chat session as specified in the section Terminating a Chat.

Either party MAY use chat renegotiation to attempt to continue the session using another of its resources. The requesting party does this by sending a feature renegotiation 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 or rejected (with a &feature; error) the switch to the new resource.

The other party SHOULD accept the switch 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.

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 SHOULD possess an 'id' attribute and 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" and MAY also contain a "reason" field.

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", with no "reason" field and the value of the "terminate" field set to "1" or "true". The client MUST mirror the 'id' attribute and &THREAD; value it received.

The ®ISTRAR; shall include 'http://jabber.org/protocol/chatneg' in its registry of Service Discovery features.

&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields shall be registered for use in Chat Session Negotiation: