Network Working Group P. Saint-Andre
Internet-Draft XMPP Standards Foundation
Intended status: Informational E. Gavita
Expires: May 14, 2008 N. Hossain
S. Loreto
Ericsson
November 11, 2007
Interworking between the Extensible Messaging and Presence Protocol
(XMPP) and the Message Session Relay Protocol (MSRP)
draft-saintandre-xmpp-msrp-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines a bidirectional protocol mapping for use by
gateways that enable the exchange of messages in the context of a
chat session between a system that implements the Extensible
Messaging and Presence Protocol (XMPP) and a system that implements
Saint-Andre, et al. Expires May 14, 2008 [Page 1]
Internet-Draft XMPP-MSRP Interworking November 2007
the Session Initiation Protocol (SIP), specifically for the latter
session-mode messages that use the Message Session Relay Protocol
(MSRP).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Architectural Assumptions . . . . . . . . . . . . . . . . 4
1.3. Connection Maintenance . . . . . . . . . . . . . . . . . . 5
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 6
2. Message Sessions . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. XMPP Formal Chat Session to MSRP . . . . . . . . . . . . . 7
2.2.1. Initiating a Formal Session . . . . . . . . . . . . . 8
2.2.2. Accepting a Formal Session . . . . . . . . . . . . . . 11
2.2.3. Terminating a Formal Session . . . . . . . . . . . . . 14
2.2.4. Canceling the Negotiation . . . . . . . . . . . . . . 16
2.2.5. Rejecting a Formal Session . . . . . . . . . . . . . . 17
2.3. XMPP Informal Session to MSRP . . . . . . . . . . . . . . 18
2.4. MSRP to XMPP formal session . . . . . . . . . . . . . . . 18
2.4.1. Initiating a Session . . . . . . . . . . . . . . . . . 19
2.4.2. Accepting a Session . . . . . . . . . . . . . . . . . 22
2.4.3. Completing the Transaction . . . . . . . . . . . . . . 23
2.4.4. Send a Message . . . . . . . . . . . . . . . . . . . . 23
2.4.5. Terminating a Session . . . . . . . . . . . . . . . . 24
2.4.6. Cancel the transaction . . . . . . . . . . . . . . . . 26
2.4.7. Rejecting a transaction . . . . . . . . . . . . . . . 27
2.5. MSRP to an XMPP Informal Session . . . . . . . . . . . . . 28
3. Security Considerations . . . . . . . . . . . . . . . . . . . 28
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. Normative References . . . . . . . . . . . . . . . . . . . 28
4.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Saint-Andre, et al. Expires May 14, 2008 [Page 2]
Internet-Draft XMPP-MSRP Interworking November 2007
1. Introduction
1.1. Overview
Within the IETF, work on instant messaging has proceeded on two
technologies that conform to the requirements defined in [IMP-REQS]:
o The Extensible Messaging and Presence Protocol [XMPP], which
consists of a formalization of the core XML streaming protocols
developed originally by the Jabber open-source community; the
relevant specifications are [XMPP] for the XML streaming layer and
[XMPP-IM] for basic presence and instant messaging extensions,
including both single messages via XMPP stanzas of type
"normal" and messaging sessions via XMPP stanzas of
type "chat".
o Various extensions to the Session Initiation Protocol [SIP] for
instant messaging and presence, as developed within the SIP for
Instant Messaging and Presence Leveraging Extensions (SIMPLE)
Working Group; the relevant specifications for instant messaging
are [SIP-MSG] for single messages (also called "pager-mode"
messaging) and [MSRP] for messaging sessions (also called
"session-mode" messaging).
Because both of these technologies have been implemented and deployed
over the Internet, it is important to clearly define bidirectional
mappings between them. Work on such mappings began with
[XMPP-SIMPLE], which defines mappings for addresses, presence, and
single messages. This document extends that work by defining a
mapping for one-to-one chat or messaging sessions.
Both XMPP and SIP/SIMPLE technologies enable end users to send
"instant messages" to other end users. The term "instant message"
usually refers to messages sent between two end-users for delivery in
close to real time (rather than messages that are stored and
forwarded to the intended recipient upon request). Generally, there
are three kinds of instant messages:
1. Single messages, which are sent from the sender to the recipient
outside the context of any one-to-one chat session or multi-user
text conference. The message is immediately delivered and not
stored in an inbox. In XMPP a single message is a
stanza of type "normal" as specified in [XMPP-IM]. In SIP/SIMPLE
a single message is sent via the MESSAGE method as specified in
[MSRP].
2. One-to-one chat messages, which are sent from the sender to the
recipient (i.e., one-to-one) in the context of a "chat session"
between the two entities. In XMPP a chat message is a
stanza of type "chat". In SIP/SIMPLE a chat message is sent
Saint-Andre, et al. Expires May 14, 2008 [Page 3]
Internet-Draft XMPP-MSRP Interworking November 2007
using an MSRP session.
3. Groupchat messages, which are sent from a sender to multiple
recipients (i.e., 2 or more) in the context of a "multi-user chat
session" or "text conference". In XMPP a groupchat message is a
stanza of type "groupchat" that is reflected from the
sender to multiple recipients by a multi-user chat service as
defined in [XEP-0045]. In SIP/SIMPLE a groupchat message is
reflected from the sender to multiple recipients by a conference
server that uses MSRP to handle groupchat sessions.
This document only covers the scenario #2 above for converting XMPP
messages of type "chat" to their corresponding SIP INVITE - MSRP
message types on the SIP/SIMPLE side.
As in [XMPP-SIMPLE], the approach taken here is to directly map
syntax and semantics from one protocol to another. One-to-one chat
sessions using XMPP message stanzas of type "chat" are specified in
[XMPP-IM], and a method for formally negotiating such a session is
specified in [XEP-0155]. One-to-one chat sessions using the SIP
MESSAGE method, the SIP INVITE method, and the Message Session Relay
Protocol (MSRP) are specified in [SIP-MSG] and [MSRP]. In
particular, this document defines a mapping between XMPP chat
sessions (as specified in [XMPP-IM] and [XEP-0155]) and the Message
Session Relay Protocol (as specified in [MSRP]).
1.2. Architectural Assumptions
In this section we remind the reader of the Architectural Assumptions
already presented in [XMPP-SIMPLE], with some small changes necessary
to support the MSRP scenario.
XMPP IM technologies consist of three element types: Clients, Servers
and Gateways. Each client can source and sink messages. Each Server
relays messages between Clients and from/to Gateways and handles
presence information. The Gateway provides transformations between
XMPP and other IM protocols.
SIP/SIMPLE technologies employ four element types: Clients, Proxies,
Presence Servers and Gateways. Each Client can source and sink
messages. A Proxy server relays messages between Clients and/or
Gateways. SIMPLE defines separable Presence Servers to maintain
presence about Client users. Gateways provide transformations
between SIMPLE and other IM protocols.
Protocol mapping between XMPP and SIP SIMPLE may occur in a number of
different entities, depending on the architecture of messaging
deployments. For instance, protocol translation could occur within a
multi-protocol server, within a multi-protocol client, or within a
Saint-Andre, et al. Expires May 14, 2008 [Page 4]
Internet-Draft XMPP-MSRP Interworking November 2007
gateway that acts as a dedicated protocol translator. This document
assumes that the protocol translation will occur within a gateway.
Specifically, we assume that the protocol translation will occur
within an "XMPP-to-MSRP gateway" that translates XMPP syntax and
semantics on behalf of an XMPP service when communicating with SIP
SIMPLE services and/or within an "MSRP-to-XMPP gateway" that
translates SIP syntax and semantics on behalf of a SIP SIMPLE service
when communicating with XMPP services.
We further assume that protocol translation will occur within a
gateway in the source domain, so that messages and presence
information generated by the user of an XMPP service will be
translated by a gateway within the trust domain of that XMPP service,
and messages and presence information generated by the user of an
MSRP service will be translated by a gateway within the trusted
domain of that MSRP service.
An architectural diagram for a typical gateway deployment is shown
below, where the entities have the following significance and the "#"
character is used to show the boundary of a trusted domain:
o juliet@example.com -- an XMPP user.
o example.com -- a XMPP service.
o x2m.example.com -- an XMPP-to-MSRP gateway.
o romeo@example.net -- an MSRP user.
o example.net -- an MSRP service.
o m2x.example.net -- an MSRP-to-XMPP gateway.
#####################################################################
# # #
# +-- m2x.example.net---#------------- example.com #
# | # | | #
# example.net------------------#--- x2m.example.com | #
# | # | #
# | # | #
# romeo@example.net # juliet@example.com #
# # #
#####################################################################
1.3. Connection Maintenance
XMPP makes use of long-lived TCP connections. If mobility affecting
Layer 3 causes a dropped connection, the connection must be re-
established. If mobility preserves the IP address, the TCP
connection will be dropped. Any TLS session and SASL associations
must be re-established if the TCP connection is dropped. XMPP binds
directly to TCP in the core specification, so the TCP session must
remain open for the entire duration of the chat/conversation. The
Saint-Andre, et al. Expires May 14, 2008 [Page 5]
Internet-Draft XMPP-MSRP Interworking November 2007
XMPP Standards Foundation does define protocol extensions enabling
transport of XMPP traffic over HTTP (refer to [XEP-0124] and
[XEP-0206]), so that individual messages are carried using HTTP and
are more robust in environments such as mobile networks, allowing for
better recovery if a TCP session is broken.
SIMPLE is similar when using MSRP. The Message Session Relay
Protocol [MSRP] is a protocol for transmitting instant messages (IM)
in the context of a session. The protocol specification describes
how the session can be negotiated and established with an offer or
answer [OFFER] using the Session Description Protocol [SDP]. In
SIMPLE, this exchange is carried using SIP as the signaling protocol.
After the TCP connection is established, if it fails for any reason,
then an MSRP endpoint MAY choose to re-create such session using a
new SDP exchange in a SIP re-INVITE. SIMPLE also uses MESSAGE
request for transporting instant messaging outside the context of a
session. The MESSAGE request is sent inside the signaling path
without establishing any dedicate connection.
1.4. Terminology
This document inherits terminology from [MSRP], [SIP], [XMPP], and
[XMPP-IM].
The capitalized 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 [TERMS].
1.5. Acknowledgements
Some text in this document was borrowed from [XMPP-SIMPLE] and from
[XEP-0155].
2. Message Sessions
2.1. Overview
The traditional model for one-to-one chat "session" in Jabber/XMPP is
for a user to simply send a message to a contact with a thread ID,
but without any formal negotiation of session parameter.
This informal approach to session initiation in XMPP can be mapped
both to SIP pager-mode messaging using the SIP MESSAGE method (as
documented in [XMPP-SIMPLE]) and to a MSRP chat session. How the
Gateway chooses to map the XMPP chat session in the SIP side is a
matter of the implementation.
Saint-Andre, et al. Expires May 14, 2008 [Page 6]
Internet-Draft XMPP-MSRP Interworking November 2007
However, in XMPP it also possibile to formally request a chat session
and negotiate its parameters (e.g., security, privacy, message
logging) before beginning the session. The protocol for doing so is
defined in [XEP-0155]. In this case, the XMPP chat session should be
translated into a MSRP session.
This document covers the mapping of both informal and formally-
negotiated XMPP chat session into a MSRP session.
2.2. XMPP Formal Chat Session to MSRP
XMPP Protocol offers two ways an XMPP user can initiate a 1-1 chat:
the first approach doesn't establish a session (this method is
referred to the "informal session" approach); the second approach
instead involves explicit negotiation of a session (this method is
referred to the "formal session" approach).
This section describes how to map an XMPP "formal session" to an MSRP
session.
The XMPP formal session is based on the protocol described in
[XEP-0155], which enable the initiation, renegotiation, and
termination of a format chat session on the XMPP side. This approach
maps to the semantic of the SIP INVITE and BYE methods.
Saint-Andre, et al. Expires May 14, 2008 [Page 7]
Internet-Draft XMPP-MSRP Interworking November 2007
XMPP User X2M GW SIP User
| | |
|(F1) (XMPP) Stanza session request |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
|(F4) (XMPP) Stanza session acceptance |
|<-------------------------| |
| |(F5) (SIP) ACK |
| |------------------------->|
|(F6) (XMPP) Stanza session completion |
|------------------------->| |
| |(F7) (MSRP) SEND |
| |------------------------->|
|(F8) (XMPP) Stanza session termination |
|------------------------->| |
| |(F9) (SIP) BYE |
| |------------------------->|
| |(F10) (SIP) 200 OK |
| |<-------------------------|
|(F11) (XMPP) Stanza acknoledgment |
| session termination |
|<-------------------------| |
2.2.1. Initiating a Formal Session
When the XMPP user ("Juliet") wants to initiate a negotiated session
with a SIP user ("Romeo"), she sends a stanza to Romeo
containing a child qualified by the
'http://jabber.org/protocol/feature-neg' namespace. The
stanza must not contain a