XEP-0155: Chat Session Negotiation

This document specifies a feature negotiation profile for initiating a one-to-one XMPP chat session.


NOTICE: This document is currently within Last Call or under consideration by the XMPP Council for advancement to the next stage in the XSF standards process.


Document Information

Series: XEP
Number: 0155
Publisher: XMPP Standards Foundation
Status: Proposed
Type: Standards Track
Version: 0.14
Last Updated: 2006-12-21
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0020, XEP-0068
Supersedes: None
Superseded By: None
Short Name: TO BE ASSIGNED
Wiki Page: <http://wiki.jabber.org/index.php/Chat Session Negotiation (XEP-0155)>

Author Information

Ian Paterson

Email: ian.paterson@clientside.co.uk
JID: ian@zoofy.com

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

Legal Notice

This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy <http://www.xmpp.org/extensions/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards 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 document 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.

Conformance Terms

The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Table of Contents

1. Introduction
2. Requirements
3. State Chart
4. Negotiating a New Chat Session
4.1. Initiating a Chat Session
4.2. Accepting a Chat Session
4.3. Rejecting a Chat Session
4.4. Completing or Canceling the Negotiation
5. Moving A Chat Session to a Different Resource
6. Renegotiating a Chat Session
7. Terminating a Chat Session
8. Implementation Notes
8.1. Auto Accept or Reject
8.2. Persisting Sessions
8.3. Sharing Presence
8.4. Unavailable Presence
8.5. Mapping to SIP
9. Security Considerations
9.1. Presence Leaks
9.2. Localization
10. IANA Considerations
11. XMPP Registrar Considerations
11.1. Protocol Namespaces
11.2. Service Discovery Features
11.3. Field Standardization
12. XML Schema
13. Acknowledgements
Notes
Revision History


1. Introduction

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 XMPP IM [1]). 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:

This proposal defines best practices for such a negotiation, re-using the protocol defined in Feature Negotiation [8].

2. Requirements

The specification addresses the following use cases:

3. State Chart

The following figure attempts to capture the state transitions in visual form.

         o
         |
        [1]
         |
PENDING  o---------------+
         |               |
         |              [3]
         |               |
        [2]-----[5]------|
         |               |
        [4]              |
         |               |
         |               |
 ACTIVE  o               |
         |               |
         +------+        |
         |      |        |
         |     [6]       |
         |      |        |
         | [7] or [8]    |
         |      |        |
         +------+        |
         |               |
         +-----[9]-------+
                         |
                         o ENDED
  

[1] A chat session negotiation is initiated when the user sends a message containing a data form of type "form" with an "accept" field.

[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".

[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".

[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".

[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".

[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".

[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".

[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.

[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".

4. Negotiating a New Chat Session

4.1 Initiating a Chat Session

In order to initiate a negotiated chat session, the initiating party ("user") sends a <message/> [9] 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 RFC 3921 [10]). 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". [11] 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 Best Practices for Handling Offline Messages [12]) using the Advanced Message Processing [13] 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 Message Archiving [14]) [15], 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 XHTML-IM [16] and Chat State Notifications [17] 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.)

Example 1. User requests chat session

<message type='normal'
         from='romeo@montague.net/orchard'
         to='juliet@capulet.com'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='form'>
      <title>Open chat with Romeo?</title>
      <field var='FORM_TYPE' type='hidden'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      <field label='Accept this chat?' type='boolean' var='accept'>
        <value>true</value>
        <required/>
      </field>
      <field label='Message logging' type='list-single' var='logging'>
        <value>mustnot</value>
        <option label='Allow message logging'>
          <value>may</value>
        </option>
        <option label='Disallow all message logging'>
          <value>mustnot</value>
        </option>
        <required/>
      </field>
      <field label="Disclosure" type="list-single" var="disclosure">
        <value>never</value>
        <option label="Guarantee disclosure not implemented">
          <value>never</value>
        </option>
        <option label="Disable all disclosures">
          <value>disabled</value>
        </option>
        <option label="Allow disclosures">
          <value>enabled</value>
        </option>
        <required/>
      </field>
      <field label='XHTML formatting'
             type='list-single'
             var='http://jabber.org/protocol/xhtml-im'>
        <value>may</value>
        <option label='Allow XHTML formatting'><value>may</value></option>
        <option label='Disallow XHTML formatting'><value>mustnot</value></option>
      </field>
      <field label='Temporarily share presence?'
             type='list-single'
             var='presence'
        <value>may</value>
        <option label='Allow temporary presence sharing'><value>may</value></option>
        <option label='Disallow temporary presence sharing'><value>mustnot</value></option>
      </field>
      <field label='Chat State Notifications'
             type='list-single'
             var='http://jabber.org/protocol/chatstates'>
        <value>may</value>
        <option label='Allow Chat State Notifications'><value>may</value></option>
        <option label='Disallow Chat State Notifications'><value>mustnot</value></option>
      </field>
      <field label='Minimum security level'
             type='list-single'
             var='security'>
        <value>c2s</value>
        <option label='Both parties must be securely connected to their servers'>
          <value>c2s</value>
        </option>
        <required/>
      </field>
      <field label='Primary written language of the chat'
             type='list-single'
             var='language'>
        <value>en</value>
        <option label='English'><value>en</value></option>
        <option label='Italiano'><value>it</value></option>
      </field>
    </x>
  </feature>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='drop' condition='deliver' value='stored'/>
  </amp>
</message>
    

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 Advanced Message Processing rule included in the request specifies otherwise) then the server MAY store the request for later delivery.

4.2 Accepting a Chat Session

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 immediate 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.

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.

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.

In the example below we assume that Juliet accepts the chat and specifies that she prefers to speak Italian with Romeo:

Example 2. Contact accepts chat and specifies parameters

<message type='normal'
         from='juliet@capulet.com/balcony'
         to='romeo@montague.net/orchard'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      <field var='accept'><value>true</value></field>
      <field var='logging'><value>mustnot</value></field>
      <field var='disclosure'><value>mustnot</value></field>
      <field var='http://jabber.org/protocol/xhtml-im'>
        <value>may</value>
      </field>
      <field var='http://jabber.org/protocol/chatstates'>
        <value>may</value>
      </field>
      <field var='security'><value>c2s</value></field>
      <field var='language'><value>it</value></field>
    </x>
  </feature>
</message>
    

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.

4.3 Rejecting a Chat Session

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 Presence Leaks). 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.

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:

Example 3. Contact declines offer and specifies reason

<message type='normal'
         from='juliet@capulet.com/balcony'
         to='romeo@montague.net/orchard'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      <field var='accept'><value>0</value></field>
    </x>
  </feature>
  <body>Sorry, can't chat now! How about tonight?</body>
</message>
    

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 <service-unavailable/> error:

Example 4. Contact returns service unavailable error

<message type='error'
         from='juliet@capulet.com/balcony'
         to='romeo@montague.net/orchard'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='form'>
      <field var='FORM_TYPE' type='hidden'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      ...
    </x>
  </feature>
  <error code='503' type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>
    

If the contact's client does not support one or more of the required features, it SHOULD return a <feature-not-implemented/> 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:

Example 5. Contact returns feature not implemented error

<message type='error'
         from='juliet@capulet.com/balcony'
         to='romeo@montague.net/orchard'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='form'>
      <field var='FORM_TYPE' type='hidden'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      ...
    </x>
  </feature>
  <error code='501' type='cancel'>
    <feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <feature xmlns='http://jabber.org/protocol/feature-neg'>
      <field var='logging'/>
    </feature>
  </error>
</message>
    

If the contact's client supports none of the options for one or more required fields, it SHOULD return a <not-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:

Example 6. Contact returns options not acceptable error

<message type='error'
         from='juliet@capulet.com/balcony'
         to='romeo@montague.net/orchard'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='form'>
      <field var='FORM_TYPE' type='hidden'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      ...
    </x>
  </feature>
  <error code='406' type='modify'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <feature xmlns='http://jabber.org/protocol/feature-neg'>
      <field var='security'/>
    </feature>
  </error>
</message>
    

4.4 Completing or Canceling the Negotiation

If the contact accepted the chat (see Accepting a Chat Session) 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. [18] 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:

Example 7. User completes negotiation and confirms session is open

<message type='normal'
         from='romeo@montague.net/orchard'
         to='juliet@capulet.com/balcony'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      <field var='accept'><value>true</value></field>
    </x>
  </feature>
  <body>I forgot what I wanted to say!</body>
</message>
    

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":

Example 8. User cancels session negotiation

<message type='normal'
         from='romeo@montague.net/orchard'
         to='juliet@capulet.com/balcony'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      <field var='accept'><value>0</value></field>
    </x>
  </feature>
</message>
    

5. Moving A Chat Session to a Different Resource

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:

Example 9. One party asks to switch session to another of its resources

<message type='normal'
         from='juliet@capulet.com/balcony'
         to='romeo@montague.net/orchard'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      <field var='continue'><value>PDA</value></field>
    </x>
  </feature>
</message>
  

The requesting party SHOULD NOT send stanzas within the session from either resource until the other party has accepted the switch to the new resource.

The other client SHOULD accept the switch automatically since the requesting party might otherwise be unable to continue the session:

Example 10. Other client accepts switch

<message type='normal'
         from='romeo@montague.net/orchard'
         to='juliet@capulet.com/balcony'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      <field var='continue'><value>PDA</value></field>
    </x>
  </feature>
</message>
  

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.

6. Renegotiating a Chat Session

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

Example 11. One party requests renegotiation

<message type='normal'
         from='juliet@capulet.com/balcony'
         to='romeo@montague.net/orchard'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='form'>
      <field var='FORM_TYPE' type='hidden'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      <field label='Renegotiate?' type='boolean' var='renegotiate'>
        <value>1</value>
        <required/>
      </field>
      <field label='Message logging' type='list-single' var='logging'>
        <value>mustnot</value>
        <option label='Disallow all message logging'>
          <value>may</value>
        </option>
        <required/>
      </field>
    </x>
  </feature>
</message>
  

The requesting party MAY continue to send stanzas within the session while it is waiting for the other party to either accept the parameters or report an error.

In order to reject the renegotiation, the other party shall send a message containing a data form of type "submit" with the 'renegotiate' field set to a value of "1" or "true".

Example 12. Other party accepts renegotiation and specifies parameters

<message type='normal'
         from='romeo@montague.net/orchard'
         to='juliet@capulet.com/balcony'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      <field var='renegotiate'><value>1</value></field>
      <field var='logging'><value>may</value></field>
    </x>
  </feature>
</message>
  

Note: Both parties MUST consider the renegotiation to be complete as soon as the parameter acceptance message has been sent (or received).

Note: The requesting party SHOULD NOT send a renegotiation completion or cancelation message (see Completing or Canceling the Negotiation).

Note: Both parties MUST ensure that they continue to comply with all the chat session negotiation parameters that were not renegotiated but had previously been agreed for this session.

In order to reject the renegotiation, the other party shall send a message containing a data form of type "submit" with the 'renegotiate' field set to a value of "0" or "false".

Example 13. Other party rejects renegotiation

<message type='normal'
         from='romeo@montague.net/orchard'
         to='juliet@capulet.com/balcony'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      <field var='renegotiate'><value>0</value></field>
      <field var='logging'><value>may</value></field>
    </x>
  </feature>
</message>
  

If the other party's client does not support one or more of the required features, it SHOULD return a <feature-not-implemented/> error. If the other party's client supports none of the options for one or more required fields, it SHOULD return a <not-acceptable/> error (see Rejecting a Chat Session). Note: In any of these cases the existing negotiated chat session parameters are maintained. Either party MAY choose to terminate the chat session only as specified in the section Terminating a Chat Session.

7. Terminating a Chat 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 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".

Example 14. One party terminates chat

<message type='normal'
         from='juliet@capulet.com/balcony'
         to='romeo@montague.net/orchard'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      <field var='terminate'><value>1</value></field>
    </x>
  </feature>
</message>
  

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", and the value of the "terminate" field set to "1" or "true" (see Encrypted Session Negotiation for a practical example). The client MUST mirror the <thread/> value it received.

Example 15. Other party acknowledges chat termination

<message type='normal'
         from='romeo@montague.net/orchard'
         to='juliet@capulet.com/balcony'>
  <thread>ffd7076498744578d10edabfe7f4a866</thread>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE'>
        <value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
      </field>
      <field var='terminate'><value>1</value></field>
    </x>
  </feature>
</message>
  

8. Implementation Notes

8.1 Auto Accept or Reject

A client MAY require a human user to approve each chat session negotiation request, however it is RECOMMENDED that it accepts or rejects automatically as many requests as possible, based on a set of user-configurable policies (see Presence Leaks).

8.2 Persisting Sessions

Chat session negotiation sometimes requires the involvement of either or both human users, and if human input is required but the user is away then session establishment may be delayed indefinitely. So, in order to minimise the number of user interruptions and delays, clients SHOULD reuse existing chat sessions whenever possible. For example, a client SHOULD NOT terminate chat sessions unless the user is going offline, even if its user closes a chat window.

8.3 Sharing Presence

If so negotiated via the 'presence' field, two parties who do not have subscriptions to each other's presence (as specified in XMPP-IM) may share presence by sending directed presence after the session is negotiated.

Example 16. User sends directed presence to contact

<presence from='romeo@montague.net/orchard' to='juliet@capulet.com/balcony'/>
    

Example 17. Contact sends directed presence to user

<presence from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard'/>
    

In accordance with the rules specified in XMPP-IM, sharing presence enables one party's server to send unavailable presence to the other party if the sending party goes offline for any reason.

8.4 Unavailable Presence

If a party receives an XMPP presence stanza of type "unavailable" from the full JID (<node@domain.tld/resource>) of the other party (i.e., the resource with which it has had an active session) during a chat session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated chat until it reconnects and receives "offline" messages).

However, the receiving party MAY assume that the other client will not be able to continue the session. [19] In that case it MUST explicitly terminate the session (see Terminating a Chat Session) -- since its assumption could be incorrect. If after terminating the session the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the chat session, then it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in XEP-0085.)

8.5 Mapping to SIP

When mapping instant messaging flows to SIP, implementations SHOULD adhere to draft-saintandre-xmpp-simple [20].

In addition, the following mappings apply to chat session negotiation:

9. Security Considerations

9.1 Presence Leaks

If a contact does not share its presence information with a user through a presence subscription (see RFC 3921) or if it blocks outbound presence notifications to the user (see Server-Based Privacy Rules [21]), then it will effectively expose its presence if it accepts the user's chat session negotiation request or returns an error to the user. Therefore, due care must be exercised in determining whether to accept the request or return an error. The contact's client SHOULD NOT automatically (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribed to the contact's presence and the contact is not blocking outbound presence notifications to the user. Note: There should be no need for the contact's client to consult the contact's block list (see Simple Communications Blocking [22]), since if the user is on the block list then the contact would not receive the request from the user in the first place.

9.2 Localization

If a client is configured to show a request <form/> to a human user instead of responding automatically, it SHOULD replace the content of the <title/> element and of all label attributes of the known and registered <field/> and <option/> elements with its own localised versions before showing the form to the user -- even if the form already appears to be in the correct language.

Note: If a client fails to localize the form, a malicious contact might, for example, either switch the labels on the 'security' and 'logging' fields, or use the <title/> to mislead the user regarding the identity of the contact.

10. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [23].

11. XMPP Registrar Considerations

11.1 Protocol Namespaces

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 XMPP Registrar Function [24].

11.2 Service Discovery Features

The XMPP Registrar [25] shall include 'http://www.xmpp.org/extensions/xep-0155.html#ns' in its registry of Service Discovery features.

Registry Submission

<var>
  <name>http://www.xmpp.org/extensions/xep-0155.html#ns</name>
  <desc>Support for Chat Session Negotiation and its FORM_TYPE</desc>
  <doc>XEP-0155</doc>
</var>
    

11.3 Field Standardization

Field Standardization for Data Forms [26] 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:

Registry Submission

<form_type>
  <name>http://www.xmpp.org/extensions/xep-0155.html#ns</name>
  <doc>XEP-0155</doc>
  <desc>
    Forms enabling negotation of a one-to-one
    chat session between two entities.
  </desc>
  <field
      var='accept'
      type='boolean'
      label='Whether to accept the invitation'/>
  <field
      var='continue'
      type='text-single'
      label='Another resource with which to continue the session'/>
  <field
      var="disclosure"
      type="list-single"
      label="Disclosure of content, decryption keys or identities">
    <option label="Entities guarantee no disclosure features
                   exist (not even disabled features)">
      <value>never</value>
    </option>
    <option label="Entities MUST NOT disclose (except for those
                   disclosures that are required by law)">
      <value>disabled</value>
    </option>
    <option label="Entities MAY disclose">
      <value>enabled</value>
    </option>
  </field>
  <field
      var='http://jabber.org/protocol/chatstates'
      type='list-single'
      label='Whether may send Chat State Notifications per XEP-0085'>
    <option label='May Send'>
      <value>may</value>
    </option>
    <option label='Must Not Send'>
      <value>mustnot</value>
    </option>
  </field>
  <field
      var='http://jabber.org/protocol/xhtml-im'
      type='list-single'
      label='Whether allowed to use XHTML-IM formatting per XEP-0071'>
    <option label='May Send'>
      <value>may</value>
    </option>
    <option label='Must Not Send'>
      <value>mustnot</value>
    </option>
  </field>
  <field
      var='language'
      type='list-single'
      label='Primary written language of the chat (each
             value appears in order of preference and
             conforms to RFC 4646 and the IANA registry)'/>
  <field
      var='logging'
      type='list-single'
      label='Whether allowed to log messages (i.e., 
             whether Off-The-Record mode is required)'>
    <option label='Allow Message Logging'>
      <value>may</value>
    </option>
    <option label='Disallow All Message Logging (i.e., must 
                   disable absolutely all message
                   logging including automatic archiving
                   -- see XEP-0136'>
      <value>mustnot</value>
    </option>
  </field>
  <field
      var='renegotiate'
      type='boolean'
      label='Whether to renegotiate the session'/>
  <field
      var='security'
      type='list-single'
      label='Minimum security level'>
    <option label='Secure connections not required'>
      <value>none</value>
    </option>
    <option label='Both parties must be securely connected to their servers'>
      <value>c2s</value>
    </option>
    <option label='Both parties must be securely connected to each other'>
      <value>e2e</value>
    </option>
  </field>
  <field
      var='terminate'
      type='boolean'
      label='Whether to terminate the session'/>
</form_type>
      

12. XML Schema

This proposal re-uses the format defined in XEP-0020 and therefore does not require a separate schema.

13. Acknowledgements

Thanks to Thomas Charron and Jean-Louis Seguineau for their feedback.


Notes

1. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.

2. XEP-0116: Encrypted Session Negotiation <http://www.xmpp.org/extensions/xep-0116.html>.

3. XEP-0136: Message Archiving <http://www.xmpp.org/extensions/xep-0136.html>.

4. XEP-0030: Service Discovery <http://www.xmpp.org/extensions/xep-0030.html>.

5. XEP-0115: Entity Capabilities <http://www.xmpp.org/extensions/xep-0115.html>.

6. RFC 3261: Session Initiation Protocol (SIP) <http://www.ietf.org/rfc/rfc3261.txt>.

7. 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 RFC 3261.

8. XEP-0020: Feature Negotiation <http://www.xmpp.org/extensions/xep-0020.html>.

9. 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).

10. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.

11. In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'; implementations MUST support both styles of lexical representation.

12. XEP-0160: Best Practices for Handling Offline Messages <http://www.xmpp.org/extensions/xep-0160.html>.

13. XEP-0079: Advanced Message Processing <http://www.xmpp.org/extensions/xep-0079.html>.

14. XEP-0136: Message Archiving <http://www.xmpp.org/extensions/xep-0136.html>.

15. 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).

16. XEP-0071: XHTML-IM <http://www.xmpp.org/extensions/xep-0071.html>.

17. XEP-0085: Chat State Notifications <http://www.xmpp.org/extensions/xep-0085.html>.

18. See Encrypted Session Negotiation for example of other instances where the user might find the values submitted by the contact unacceptable.

19. In general, if a party is not subscribing to the other party's presence then it will never assume the other party is is unable to continue a session.

20. Basic Messaging and Presence Interoperability between the Extensible Messaging and Presence Protocol (XMPP) and Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) <http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-09.txt> (work in progress).

21. XEP-0016: Server-Based Privacy Rules <http://www.xmpp.org/extensions/xep-0016.html>.

22. XEP-0191: Simple Communications Blocking <http://www.xmpp.org/extensions/xep-0191.html>.

23. 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/>.

24. XEP-0053: XMPP Registrar Function <http://www.xmpp.org/extensions/xep-0053.html>.

25. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.

26. XEP-0068: Field Data Standardization for Data Forms <http://www.xmpp.org/extensions/xep-0068.html>.


Revision History

Version 0.14 (2006-12-21)

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.

(psa/ip)

Version 0.13 (2006-11-27)

Added disclosure field; changed namespace

(ip)

Version 0.12 (2006-11-10)

Removed accept field from renegotiation forms

(ip)

Version 0.11 (2006-11-03)

Removed reason field; added new implementation notes; many clarifications including the handling of required fields

(ip)

Version 0.10 (2006-10-31)

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.

(ip)

Version 0.9 (2006-10-08)

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.

(ip)

Version 0.8 (2006-10-02)

Added continue field and optional terminate acknowledgement; specified renegotiation failure proceedure; added context to Introduction; changed unavailable presence handling; renamed logging field to otr.

(ip)

Version 0.7 (2006-07-14)

Added secure field from XEP-0116.

(psa)

Version 0.6 (2006-07-13)

Specified that a client must re-initiate if it receives presence unavailable; changed document type to Standards Track.

(psa)

Version 0.5 (2006-01-24)

Added renegotiate use case.

(psa)

Version 0.4 (2006-01-03)

Added terminate use case; further specified mapping to SIP.

(psa)

Version 0.3 (2005-12-30)

Further specified use of id attribute and thread element.

(psa)

Version 0.2 (2005-07-15)

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.

(psa)

Version 0.1 (2005-07-14)

Initial version.

(psa)

Version 0.0.1 (2005-07-12)

First draft.

(psa)


END