This JEP specifies a feature negotiation profile for initiating a one-to-one chat session.
WARNING: This Informational JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the best practice or protocol profile described herein is encouraged in exploratory implementations, although production systems should not deploy implementations of this protocol until it advances to a status of Draft.
Status: Experimental
Type: Informational
Number: 0155
Version: 0.1
Last Updated: 2005-07-14
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0020, JEP-0068
Supersedes: None
Superseded By: None
Short Name: Not yet assigned
Email: stpeter@jabber.org
JID: stpeter@jabber.org
This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
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. This information approach to initiation of a chat session is perfectly acceptable in most contexts, environments, and cultures. However, in some contexts (e.g., if the parties are unknown to each other or have not exchanged presence), environments (e.g., mobile telephony), and cultures (e.g., an organization in which one would not simply beginning chatting with a superior), it may be desirable to formally request the chat and negotiate its parameters before beginning the chat session. This proposal defines best practices for such a negotiation, using the protocol defined in Feature Negotiation [1].
In order to negotiate a 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 but containing no <body/> or other standard child elements (as specified in RFC 3921 [2]). 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 MAY include an 'id' attribute for tracking purposes. The data form MUST contain a hidden FORM_TYPE field whose value is "http://jabber.org/protocol/chatneg".
The following is an example of a negotiation request:
Example 1. User requests chat session
<message type='normal'
from='romeo@montague.net/orchard'
to='juliet@capulet.com'
id='neg1'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/chatneg</value>
</field>
<field type='boolean'
label='Accept this chat?'
var='accept'>
<value>1</value>
</field>
<field type='boolean'
label='Enable XHTML Formatting?'
var='http://jabber.org/protocol/xhtml-im'>
<value>0</value>
</field>
<field type='boolean'
label='Enable Chat State Notifications?'
var='http://jabber.org/protocol/chatstates'>
<value>0</value>
</field>
</x>
</feature>
</message>
In the foregoing example, Romeo requests a chat with Juliet and also queries her regarding whether she wants to support XHTML-IM [3] and Chat State Notifications [4] extensions.
Juliet's server delivers Romeo's request to her most available resource (which happens to be "balcony"). We assume that Juliet accepts the chat and specifies that she does not want to use XHTML formatting but that she does want to use Chat State Notifications:
Example 2. Contact accepts offer and specifies parameters
<message type='normal'
from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'
id='neg1'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/chatneg</value>
</field>
<field type='boolean' var='accept'>
<value>1</value>
</field>
<field type='boolean' var='http://jabber.org/protocol/xhtml-im'>
<value>0</value>
</field>
<field type='boolean' var='http://jabber.org/protocol/chatstates'>
<value>1</value>
</field>
</x>
</feature>
</message>
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 <service-unavailable/> error (but MAY return no error if, for example, Juliet does not want to reveal her presence to Romeo for whatever reason):
Example 3. Contact returns service unavailable error
<message type='error'
from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'
id='neg1'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/chatneg</value>
</field>
<field type='boolean' var='accept'>
<value>1</value>
<required/>
</field>
<field type='boolean' var='http://jabber.org/protocol/xhtml-im'>
<value>0</value>
</field>
<field type='boolean' var='http://jabber.org/protocol/chatstates'>
<value>1</value>
</field>
</x>
</feature>
<error code='503' type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</message>
If Juliet's client does not support one of the required features, it SHOULD return a <feature-not-implemented/> error (but MAY return no error if, for example, Juliet does not want to reveal her presence to Romeo for whatever reason):
Example 4. Contact returns feature not implemented error
<message type='error'
from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'
id='neg1'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/chatneg</value>
</field>
<field type='boolean' var='accept'>
<value>1</value>
<required/>
</field>
<field type='boolean' var='http://jabber.org/protocol/xhtml-im'>
<value>0</value>
</field>
<field type='boolean' var='http://jabber.org/protocol/chatstates'>
<value>1</value>
</field>
</x>
</feature>
<error code='501' type='cancel'>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</message>
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".
A client MAY require a human user to approve each chat session negotiation request or MAY auto-accept and auto-reject requests based on some configurable policy.
If a contact accepts a user's request or returns an error to the user, the user will effectively discover the contact's presence (at least the presence of one of the contact's resources). Due care must be exercised in determining whether to accept the request or return an error (e.g., the contact's client must not automatically accept the user's request or return an error to the user if the user is in the contact's block list).
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [5].
To follow.
This proposal defines best practices for use of JEP-0020 and therefore does not require a separate schema.
1. JEP-0020: Feature Negotiation <http://www.jabber.org/jeps/jep-0020.html>.
2. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.
3. JEP-0071: XHTML-IM <http://www.jabber.org/jeps/jep-0071.html>.
4. JEP-0085: Chat State Notifications <http://www.jabber.org/jeps/jep-0085.html>.
5. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
END