Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text ChatCisco Systems, Inc.1899 Wynkoop Street, Suite 600DenverCO80202USA+1-303-308-3282psaintan@cisco.comEricssonHirsalantie 1102420JorvasFinlandSalvatore.Loreto@ericsson.comEricssonDecarie BoulevardTown of Mount RoyalQuebecCanadaeddy.gavita@ericsson.comEricssonDecarie BoulevardTown of Mount RoyalQuebecCanadaNazin.Hossain@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 and the Extensible Messaging and Presence Protocol 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 . 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 .SIP-based chat sessions using the SIP INVITE and SEND request types are specified in .In SIMPLE, 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. To overcome the disparity between these approaches, a gateway that wishes to map between SIP and XMPP for one-to-one chat sessions needs to maintain some additional state, as described below.The discussion venue for this document is the mailing list of the DISPATCH WG; visit https://www.ietf.org/mailman/listinfo/dispatch for subscription information and discussion archives.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.First the XMPP user would generate an XMPP chat message.The local SIP-to-XMPP gateway at the SIMPLE server would then determine if Romeo supports MSRP. If so, the SIP-to-XMPP gateway would initiate an MSRP session with Romeo on Juliet's behalf.Here we assume that Romeo accepts the MSRP session request.The XMPP-to-SIP gateway then acknowledges the session acceptance on behalf of Romeo.The XMPP-to-SIP gateway then transforms the original XMPP chat message into MSRP.Romeo can then send a reply using his MSRP user agent.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.When an MSRP client sends messages through a gateway to an XMPP client that does not support formal sessinos, the order of events is as follows.Detailed security considerations for instant messaging protocols are given in , for SIP-based instant messaging in (see also ), and for XMPP-based instant messaging in (see also ).This document specifies methods for exchanging instant messages through a gateway that translates between SIP and XMPP. Such a gateway MUST be compliant with the minimum security requirements of the instant messaging protocols for which it translates (i.e., SIP 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 user agents that interface through a SIMPLE-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 recommended to use for instant messages.This document requests no actions of IANA.Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): CoreAs 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.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 FormatThe 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]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.Session Initiation Protocol (SIP) Extension for Instant MessagingInstant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. [STANDARDS TRACK] Some text in this document was borrowed from .Thanks to Adrian Georgescu, Saul Ibarra, and Tory Patnoe for their feedback.