In order to initiate a negotiated chat session, the initiating party ("user") sends a &MESSAGE; 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). 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 "http://www.xmpp.org/extensions/xep-0155.html#ns" 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.
+
In order to initiate a negotiated chat session, the initiating party ("user") sends a &MESSAGE; 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). 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.
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 is able to disallow all message logging (see &xep0136;) 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 Message Archiving)., whether she wants to temporarily share presence for this session (see the Sharing Presence 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 Encrypted Session Negotiation). 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 XMPP Registrar Considerations section of this document.)
If the contact's client does not support feature negotiation or does not support the "http://www.xmpp.org/extensions/xep-0155.html#ns" FORM_TYPE, it SHOULD return a &unavailable; error:
+
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:
Until this specification advances to a status of Draft, its associated namespace (as used in the negotiation FORM_TYPE) shall be "http://www.xmpp.org/extensions/xep-0155.html#ns"; upon advancement of this specification, the XMPP Registrar shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.
+
The ®ISTRAR; includes 'urn:xmpp:chatneg' in its registry of protocol namespaces (see &NAMESPACES;).
-
The ®ISTRAR; shall include 'http://www.xmpp.org/extensions/xep-0155.html#ns' in its registry of Service Discovery features.
+
The XMPP Registrar includes 'urn:xmpp:chatneg' in its registry of Service Discovery features (see &DISCOFEATURES;).
- http://www.xmpp.org/extensions/xep-0155.html#ns
+ urn:xmpp:chatnegSupport for Chat Session Negotiation and its FORM_TYPEXEP-0155
]]>
-
&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:
+
&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields are registered for use in Chat Session Negotiation (see &FORMTYPES;):
- http://www.xmpp.org/extensions/xep-0155.html#ns
+ urn:xmpp:chatnegXEP-0155
Forms enabling negotation of a one-to-one
@@ -715,7 +721,7 @@ PENDING o---------------+
-
This proposal re-uses the format defined in XEP-0020 and therefore does not require a separate schema.
+
This proposal re-uses the format defined in XEP-0020 and therefore does not require a dedicated schema.
Thanks to Thomas Charron and Jean-Louis Seguineau for their feedback.