Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions&yetP.O. Box 787ParkerCO80134USApeter@andyet.comEricssonHirsalantie 1102420JorvasFinlandSalvatore.Loreto@ericsson.com
RAI
Text ChatInstant MessagingSession Initiation ProtocolSIPMessage Sessions Relay ProtocolMSRPExtensible Messaging and Presence ProtocolXMPPThis document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).Both the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) can be used for the purpose of one-to-one text chat over the Internet. To ensure interworking between these technologies, it is important to define bidirectional protocol mappings.The architectural assumptions underlying such protocol mappings are provided in , including mapping of addresses and error conditions. This document specifies mappings for one-to-one text chat sessions (sometimes called "session-mode" messaging); in particular, this document specifies mappings between XMPP messages of type "chat" and the Message Session Relay Protocol (MSRP) , which is commonly used in SIP-based systems for chat functionality (although note that MSRP is not conjoined to SIP, and can be used by non-SIP technologies). Mappings for single instant messages and groupchat are provided in separate documents.The approach taken here is to directly map syntax and semantics from one protocol to another. The mapping described herein depends on the protocols defined in the following specifications:XMPP chat sessions using message stanzas of type "chat" are specified in .MSRP chat sessions using the SIP INVITE and SEND request types are specified in .In SIP-based systems that use MSRP, a chat session is formally negotiated just as any other session type is using SIP. By contrast, a one-to-one chat "session" in XMPP is an informal construct and is not formally negotiated: a user simply sends a message of type "chat" to a contact, the contact then replies to the message, and the sum total of such messages exchanged during a defined period of time is considered to be a chat session (ideally tied together using an XMPP <thread/> element as described in Section 5.1 of ). To overcome the disparity between these approaches, a gateway that wishes to map between SIP/MSRP and XMPP for one-to-one chat sessions needs to maintain some additional state, as described below.The documents in this series are intended for use by software developers who have an existing system based on one of these technologies (e.g., SIP), and would like to enable communication from that existing system to systems based on the other technology (e.g., XMPP). We assume that readers are familiar with the core specifications for both SIP and XMPP , with the base document for this series , and with the following chat-related specifications:The Message Session Relay Protocol (MSRP) Extensible Messaging and Presence Protocol: Instant Messaging and Presence Indication of Message Composition for Instant Messaging Chat State Notifications A number of terms used here are explained in , , , and .In flow diagrams, SIP/MSRP traffic is shown using arrows such as "***>" whereas XMPP traffic is shown using arrows such as "...>".The key words "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 .In XMPP, the "informal session" approach is to simply send someone a <message/> of type "chat" without starting any session negotiation ahead of time (as described in ). The XMPP "informal session" approach maps very well into a SIP MESSAGE request, as described in . However, the XMPP informal session approach can also be mapped to MSRP if the XMPP-to-SIP gateway maintains additional state. The order of events is as follows.The mapping of XMPP syntax to SIP syntax SHOULD be as shown in the following table. (Mappings for several aspects not mentioned here are specified in .)First the XMPP user would generate an XMPP chat message.Upon receiving such a message stanza, the XMPP server needs to determine the identity of the domainpart in the 'to' address, which it does by following the procedures explained in Section 5 of . If the domain is a SIP domain, the XMPP server will hand off the message stanza to an XMPP-to-SIP gateway or connection manager that natively communicates with MSRP-aware SIP servers.The XMPP-to-SIP gateway at the XMPP server would then initiate an MSRP session with Romeo on Juliet's behalf (since there is no reliable way for the gateway to determine if Romeo's client supports MSRP, it simply needs to guess).Here we assume that Romeo accepts the MSRP session request.The XMPP-to-SIP gateway then acknowledges the session acceptance on behalf of Juliet.The XMPP-to-SIP gateway then transforms the original XMPP chat message into MSRP.Romeo can then send a reply using his MSRP client.The SIP-to-XMPP gateway would then transform that message into appropriate XMPP syntax for routing to the intended recipient.When the MSRP user wishes to end the chat session, the user's MSRP client sends a SIP BYE.The BYE is then acknowledged by the XMPP-to-SIP gateway.Because there is no formal session on the XMPP side, there is no corresponding communication from the gateway to the XMPP user. However, it is reasonable for the gateway to send a "gone" chat state notification , as described under .When an MSRP client sends messages through a gateway to an XMPP client, the order of events is as follows.The mapping of SIP syntax to XMPP syntax SHOULD be as shown in the following table. (Mappings for several aspects not mentioned here are specified in .)The protocol flow begins when Romeo starts a chat session with Juliet.Upon receiving the INVITE, the SIP (MSRP) server needs to determine the identity of the domain portion of the Request-URI or To header, which it does by following the procedures explained in Section 5 of . If the domain is an XMPP domain, the SIP server will hand off the INVITE to an associated MSRP-to-XMPP gateway or connection manager that natively communicates with XMPP servers.Both XMPP and MSRP enable a client to receive notifications when a person's conversation partner is composing an instant message within the context of a chat session.For XMPP, the Chat State Notifications specification defines five states: active, inactive, gone, composing, and paused. Some of these states are related to the act of message composition (composing, paused), whereas others are related to the sender's involvement with the chat session (active, inactive, gone). Note that the "gone" chat state is not to be confused with the <gone/> stanza error condition defined in .For MSRP (and SIP/SIMPLE in general), the Indication of Message Composition for Instant Messaging specification defines two states: idle and active. Here the idle state indicates that the sender is not actively composing a message, and the active state indicates that the sender is indeed actively composing a message (the sending client simply toggles between the two states, changing to active if the user is actively composing a message and changing to idle if the user is no longer actively composing a message).Because the XEP-0085 states can represent information that is not captured in RFC 3994, gateways can either (a) map only the composing-related states or (b) map all the XEP-0085 states.The following mappings are suggested.Although there is no direct mapping for the "gone" chat state to an isComposing event, receipt of the "gone" state at an XMPP-to-MSRP gateway can serve as a trigger for terminating the formal chat session within MSRP, i.e., for sending a SIP BYE for the session from the XMPP-to-MSRP gateway to the SIP user. The following examples illustrate this indirect mapping (which would occur after step F14 in Figure 1).Similarly, receipt of a SIP BYE message at an MSRP-to-XMPP gateway can server as a trigger for sending a "gone" chat state notification to the XMPP user. The following examples illustrate this indirect mapping (which would occur after step F30 in Figure 2).To enable these uses, gateways that support chat state notifications MUST support the "gone" state (which is merely recommended, not required, by ).It is also reasonable for gateways to implement timers that automatically trigger a "gone" chat state if the XMPP user has not sent a message within the "session" for a given amount of time.Both XMPP and MSRP enable a client to receive notifications when a message has been received by the intended recipient.For XMPP, the Message Receipts specification defines a method and XML namespace for requesting and returning indications that a message has been received by a client controlled by the intended recipient.For MSRP, a native reporting feature is included, in the form of REPORT chunks (see Sections 7.1.2 and 7.1.3 of ).Examples follow.First, the XMPP user sends a message containing a request for delivery notification.Next, the recipient returns a report.Relevant discussion of internationalized text in messages can be found in .This document requests no actions of IANA.Detailed security considerations for instant messaging protocols are given in , for MSRP chat in (see also when SIP is used to negotiate MSRP sessions), and for XMPP-based instant messaging in (see also ). The security considerations provided in also apply.This document specifies methods for exchanging instant messages through a gateway that translates between SIP/MSRP and XMPP. Such a gateway MUST be compliant with the minimum security requirements of the textual chat protocols for which it translates (i.e., MSRP and XMPP). The addition of gateways to the security model of instant messaging specified in introduces some new risks. In particular, end-to-end security properties (especially confidentiality and integrity) between instant messaging clients that interface through an MSRP-XMPP gateway can be provided only if common formats are supported. Specification of those common formats is out of scope for this document, although it is suggested to use for instant messages.Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
SIP: Session Initiation ProtocolThis document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK] Common Presence and Instant Messaging (CPIM): Message FormatIndication of Message Composition for Instant MessagingIn instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. [STANDARDS-TRACK]The Message Session Relay Protocol (MSRP)This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS TRACK]Extensible Messaging and Presence Protocol (XMPP): CoreThe Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and PresenceThis document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK]Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error HandlingAs a foundation for the definition of application-specific, bi-directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions. [STANDARDS-TRACK]Chat State Notificationsstpeter@jabber.orgdizzyd@jabber.orgMessage Delivery Receiptsstpeter@jabber.orgjhildebr@cisco.comInterworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant MessagingThis document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).Instant Messaging / Presence Protocol RequirementsSightPath, Inc.135 Beaver StreetWalthamMA02452USmday@alum.mit.eduMicrosoft CorporationOne Microsoft WayRedmondWA98052USsonuag@microsoft.comInto Networks, Inc.150 Cambridgepark DriveCambridgeMA02140USjesse@intonet.comPresence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users.Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet.Special thanks to Eddy Gavita and Nazin Hossain for co-authoring an early version of this document.Thanks to Mary Barnes, Ben Campbell, Dave Crocker, Adrian Georgescu, Philipp Hancke, Saul Ibarra Corretge, Tory Patnoe, and Matt Ryan for their feedback.The authors gratefully acknowledge the assistance of Markus Isomaki and Yana Stamcheva as the working group chairs and Gonzalo Camarillo and Alissa Cooper as the sponsoring Area Directors.Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier versions of this document.