Request for Comments: 3922 Jabber Software Foundation
Category: Standards Track October 2004
Mapping the Extensible Messaging and Presence Protocol (XMPP) to
Common Presence and Instant Messaging (CPIM)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo describes a mapping between the Extensible Messaging and
Presence Protocol (XMPP) and the Common Presence and Instant
Messaging (CPIM) specifications.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 4
4. Syntax Mapping of Instant Messages . . . . . . . . . . . . . . 5
5. Syntax Mapping of Presence Information . . . . . . . . . . . . 13
6. XMPP-CPIM Gateway as Presence Service . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Author’s Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
1.1. Overview
The Instant Messaging and Presence (IMPP) Working Group has defined
an abstract framework for interoperability among instant messaging
(IM) and presence systems that are compliant with [IMP-REQS]. This
framework is commonly called Common Presence and Instant Messaging or
"CPIM". The CPIM family of specifications include a Common Profile
for Instant Messaging [CPIM] (also called CPIM), a Common Profile for
Presence [CPP], a CPIM Message Format [MSGFMT], and a Common Presence
Information Data Format [PIDF]. (Note: To prevent confusion, Common
Presence and Instant Messaging is referred to herein collectively as
"the CPIM specifications", whereas the Common Profile for Instant
Messaging is referred to as "CPIM".)
This memo describes how the Extensible Messaging and Presence
Protocol ([XMPP-CORE], [XMPP-IM]) maps to the abstract model
contained in the CPIM specifications, mainly for the purpose of
establishing gateways between XMPP services and non-XMPP services
that conform to [IMP-REQS]. Such a gateway, referred to herein as an
"XMPP-CPIM gateway", may be established to interpret the protocols of
one service and translate them into the protocols of the other
service. We can visualize this relationship as follows:
+-------------+ +-------------+ +------------+
| | | | | |
| XMPP | | XMPP-CPIM | | Non-XMPP |
| Service | <----> | Gateway | <----> | Service |
| | | | | |
+-------------+ +-------------+ +------------+
This memo defines a mapping for use by a gateway that translates
between XMPP and a non-XMPP protocol via the CPIM specifications.
Such a gateway is not an intermediate hop on a network of non-XMPP
servers (whose native formats may or may not be defined by the CPIM
specifications), but a dedicated translator between XMPP and a
non-XMPP protocol, where the CPIM specifications define the common
formats into which the protocols are translated for purposes of
interworking.
The mapping defined herein applies to instant messages and presence
information that are not encrypted or signed for end-to-end security.
For information about secure communications to or from an XMPP
service through an XMPP-CPIM gateway, refer to [XMPP-E2E].
1.2. Terminology
This memo inherits vocabulary defined in [IMP-MODEL]. Terms such as
CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN , PRESENCE SERVICE,
PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same meaning as
defined therein.
This memo also inherits vocabulary defined in [XMPP-CORE]. Terms
such as ENTITY, NODE IDENTIFIER, DOMAIN IDENTIFIER, RESOURCE
IDENTIFIER, MESSAGE STANZA, and PRESENCE STANZA are used in the same
meaning as defined therein.
1.3. Conventions Used in this Document
The capitalized 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
[TERMS].
2. Approach
XMPP and CPIM are distinctly foreign technologies. Therefore, care
must be taken in mapping between XMPP and the abstract syntax defined
by the CPIM specifications.
At root, XMPP is a data transport protocol for streaming XML elements
(called "stanzas") between any two endpoints on the network; message
and presence stanzas are two of the core data elements defined in
XMPP and are often used to exchange instant messages and presence
information between IM users (although the inherent extensibility of
XML enables applications to use the general semantics of these stanza
types for other purposes). XMPP is not based on [MIME]; instead,
[XMPP-CORE] defines XML schemas for both message and presence stanzas
(for example, the <body/> child of a message stanza contains XML
character data that is usually intended to be read by a human user).
The CPIM specifications provide common formats for instant messaging
and presence through two [MIME] content-types: "Message/CPIM" for
messages ([MSGFMT]) and "application/pidf+xml" for presence ([PIDF]).
The syntax of "Message/CPIM" objects is similar to but stricter than
that defined in [RFC2822], and provides the ability to include
arbitrary MIME media types [MIMETYPES]. By contrast, each
"application/pidf+xml" object is a complete XML document whose
structure is defined by an XML schema.
The approach taken herein is to specify mappings from XMPP elements
and attributes to the headers and MIME formats defined by [MSGFMT]
and [PIDF] in order to comply with the semantics defined by [CPIM]
and [CPP]. Naturally, mappings in the opposite direction are
provided as well.
3. Address Mapping
3.1. Overview
Address mapping may be required since the address formats used to
identify XMPP entities (specified in [XMPP-CORE]) are different from
those used to identify instant inboxes (the im: URI scheme specified
in [CPIM]) and presentities (the pres: URI scheme specified in
[CPP]). In particular, different characters are allowed in im: and
pres: URIs than are allowed in XMPP addresses:
o The following [US-ASCII] characters are allowed in im:/pres: URIs
but not in XMPP addresses: #26; (&), #27; (’), and #2f; (/).
o Many non-US-ASCII (specifically, UTF-8) characters are allowed in
XMPP addresses but not allowed in im:/pres: URIs, since XMPP
allows internationalized local-part addresses.
Note: In this document we discuss characters allowed in local-part
addresses only (i.e., we have ruled the mapping of domain names as
out of scope for the initial version of this document, since it is a
matter for the Domain Name System and the translation of fully
internationalized domain names).
3.2. XMPP to CPIM
The following is a high-level algorithm for mapping an XMPP address
to an im: or pres: URI:
1. Split XMPP address into node identifier (local-part; mapping
described in remaining steps), domain identifier (hostname;
mapping is out of scope), and resource identifier (specifier for
particular device or connection; discard this for cross-system
interoperability)
2. Apply Nodeprep profile of [STRINGPREP] (as specified in
[XMPP-CORE]) for canonicalization (OPTIONAL)
3. Translate #26; to &, #27; to ’, and #2f; to / respectively
4. For each byte, if the byte is not in the set A-Za-z0-9!$*.?_~+=
then change to %hexhex as described in Section 2.2.5 of
[URL-GUIDE]
5. Combine resulting local-part with mapped hostname to form
local@domain address
6. Prepend with ’im:’ scheme (for XMPP <message/> stanzas) or
’pres:’ scheme (for XMPP <presence/> stanzas)
3.3. CPIM to XMPP
The following is a high-level algorithm for mapping an im: or pres:
URI to an XMPP address:
1. Remove URI scheme
2. Split at the first ’@’ character into local-part and hostname
(mapping the latter is out of scope)
3. Translate %hexhex to equivalent octets as described in Section
2.2.5 of [URL-GUIDE]
4. Treat result as a UTF-8 string
5. Translate & to #26;, ’ to #27;, and / to #2f respectively
6. Apply Nodeprep profile of [STRINGPREP] (as specified in
[XMPP-CORE]) for canonicalization (OPTIONAL)
7. Recombine local-part with mapped hostname to form local@domain
address
4. Syntax Mapping of Instant Messages
This section describes how a gateway SHOULD map instant messages
between an XMPP service and a non-XMPP service using a "Message/CPIM"
object as the bearer of encapsulated text content in order to comply
with the instant messaging semantics defined by [CPIM].
4.1. Message Syntax Mapping from XMPP to CPIM Specifications
This section defines the mapping of syntax primitives from XMPP
message stanzas to "Message/CPIM" objects with encapsulated text
content.
Note: As specified in [MIME], the default Content-type of a MIME
object is "Content-type: text/plain; charset=us-ascii". Because XMPP
uses the [UTF-8] character encoding exclusively, the encapsulated
MIME object generated by an XMPP-CPIM gateway MUST set the
"Content-type" MUST be set to "text/plain" and the charset MUST be
set to "utf-8".
4.1.1. From Address
The ’from’ attribute of an XMPP message stanza maps to the ’From’
header of a "Message/CPIM" object. In XMPP, the sender’s server
stamps or validates the "from" address and sets its value to the full
<user@host/resource> negotiated between client and server during
authentication and resource binding as defined in [XMPP-CORE]. Thus
an XMPP-CPIM gateway will receive from the sender’s XMPP server a
message stanza containing a "from" address of the form
<user@host/resource>. To map the ’from’ attribute of an XMPP message
stanza to the ’From’ header of a "Message/CPIM" object, the gateway
MUST remove the resource identifier, MUST append the "im:" Instant
Messaging URI scheme to the front of the address, and MAY include a
CPIM "Formal-name" for the sender (if known).
Example: From Address Mapping
XMPP ’from’ attribute
<message from=’juliet@example.com/balcony’>
...
</message>
CPIM ’From’ header
From: Juliet Capulet <im:juliet@example.com>
4.1.2. To Address
The ’to’ attribute of an XMPP message stanza maps to the ’To’ header
of a "Message/CPIM" object. In XMPP, the sender SHOULD include a
’to’ attribute on a message stanza, and MUST include it if the
message is intended for delivery to another user. Thus an XMPP-CPIM
gateway will receive from the sender’s XMPP server a message stanza
containing a "to" address of the form <user@host> or
<user@host/resource>. To map the ’to’ attribute of an XMPP message
stanza to the ’To’ header of a "Message/CPIM" object, the gateway
MUST remove the resource identifier (if included), MUST append the
"im:" Instant Messaging URI scheme to the front of the address, and
MAY include a CPIM "Formal-name" for the recipient (if known).
Example: To Address Mapping
XMPP ’to’ attribute
<message to=’romeo@example.net/orchard’>
...
</message>
CPIM ’To’ header
To: Romeo Montague <im:romeo@example.net>
4.1.3. Stanza ID
An XMPP message stanza MAY possess an ’id’ attribute, which is used
by the sending application for the purpose of tracking stanzas and is
not a globally-unique identifier such as is defined by the MIME
Content-ID header. Because the XMPP ’id’ attribute does not have the
same meaning as the MIME Content-ID header, it SHOULD NOT be mapped
to that header; however, if the ’id’ is known to be unique (e.g., if
it is generated to be unique by the XMPP server and that fact is
known by the XMPP-CPIM gateway), then it SHOULD be so mapped.
4.1.4. Message Type
An XMPP message stanza MAY possess a ’type’ attribute, which is used
by the sending application to capture the conversational context of
the message. There is no mapping of an XMPP ’type’ attribute to a
"Message/CPIM" header, common MIME features, or encapsulated text
content. Therefore if an XMPP stanza received by an XMPP-CPIM
gateway possesses a ’type’ attribute, the gateway SHOULD ignore the
value provided.
4.1.5. Message Thread
An XMPP message stanza MAY contain a <thread/> child element to
specify the conversation thread in which the message is situated.
There is no mapping of an XMPP <thread/> element to a "Message/CPIM"
header, common MIME features, or encapsulated text content. Therefore
if an XMPP message stanza received by an XMPP-CPIM gateway contains a
<thread/> child element, the gateway SHOULD ignore the value
provided.
4.1.6. Message Subject
An XMPP message stanza MAY include a <subject/> child element. If
included, it maps to the ’Subject’ header of a "Message/CPIM" object.
To map the XMPP <subject/> element to the ’Subject’ header of a
"Message/CPIM" object, the gateway SHOULD simply map the XML
character data of the XMPP <subject/> element to the value of the
’Subject’ header. The <subject/> element MAY include an ’xml:lang’
attribute specifying the language in which the subject is written. If
an ’xml:lang’ attribute is provided, it MUST be mapped by including
’;lang=tag’ after the header name and colon, where ’tag’ is the value
of the ’xml:lang’ attribute.
Example: Subject Mapping
XMPP <subject/> element
<subject>Hi!</subject>
<subject xml:lang=’cz’>Ahoj!</subject>
CPIM ’Subject’ header
Subject: Hi!
Subject:;lang=cz Ahoj!
4.1.7. Message Body
The <body/> child element of an XMPP message stanza is used to
provide the primary meaning of the message. The XML character data
of the XMPP <body/> element maps to the encapsulated text message
content.
Example: Message Body
XMPP message <body/>
<message>
<body>Wherefore art thou, Romeo?</body>
</message>
Encapsulated MIME text content
Content-type: text/plain; charset=utf-8
Content-ID: <123456789@example.net>
Wherefore art thou, Romeo?
4.1.8. Message Extensions
As defined in [XMPP-CORE], an XMPP message stanza may contain
"extended" content in any namespace in order to supplement or extend
the semantics of the core message stanza. With the exception of
extended information qualified by the
’urn:ietf:params:xml:ns:xmpp-e2e’ namespace as defined in [XMPP-E2E],
an XMPP-CPIM gateway SHOULD ignore such information and not pass it
through the gateway to the intended recipient. No mapping for such
information is defined.
4.1.9. Gateway-Generated CPIM Syntax
CPIM specifies the existence of "Message/CPIM" headers in addition to
those described above, but there is no exact analogue for those
headers in the core XMPP specifications. These include:
o cc -- specifies the address of an entity that is to receive a
"courtesy copy" of the message (i.e., a non-primary addressee)
o DateTime -- specifies the datetime at which the message was sent
o NS -- specifies the namespace of a feature extension
o Require -- specifies mandatory-to-recognize features
An XMPP-CPIM gateway MAY independently generate such headers based on
its own information (e.g., the datetime at which it received a
message stanza from an XMPP entity) or based on data encoded in
non-core XMPP extensions, but rules for doing so are out of scope for
this memo.
4.2. Message Syntax Mapping from CPIM Specifications to XMPP
This section defines the mapping of syntax primitives from
"Message/CPIM" objects with encapsualted text content to XMPP message
stanzas.
4.2.1. From Address
The ’From’ header of a "Message/CPIM" object maps to the ’from’
attribute of an XMPP message stanza. To map the CPIM ’From’ header
to the XMPP ’from’ attribute, the gateway MUST remove the "im:"
Instant Messaging URI scheme from the front of the address and MUST
remove the CPIM "Formal-name" (if provided).
Example: From Address Mapping
CPIM ’From’ header
From: Romeo Montague <im:romeo@example.net>
XMPP ’from’ attribute
<message from=’romeo@example.net’>
...
</message>
4.2.2. To Address
The ’To’ header of a "Message/CPIM" object maps to the ’to’ attribute
of an XMPP message stanza. To map the CPIM ’To’ header to the XMPP
’to’ attribute, the gateway MUST remove the "im:" Instant Messaging
URI scheme from the front of the address and MUST remove the CPIM
"Formal-name" (if provided). If the gateway possesses knowledge of
the resource identifier in use by the XMPP entity, the gateway MAY
append the resource identifier to the address.
Example: To Address Mapping
CPIM ’To’ header
To: Juliet Capulet <im:juliet@example.com>
XMPP ’to’ attribute
<message to=’juliet@example.com/balcony’>
...
</message>
4.2.3. Courtesy Copy
The core XMPP specification does not include syntax for specifying a
"courtesy copy" (non-primary addressee) for a message stanza.
Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
that contains a ’cc’ header, it SHOULD NOT pass the information
contained in that header on to the XMPP recipient.
4.2.4. DateTime Header
The core XMPP specification does not include syntax for specifying
the datetime at which a message stanza was sent. Therefore, if an
XMPP-CPIM gateway receives a "Message/CPIM" object that contains a
’DateTime’ header, it SHOULD NOT pass the information contained in
that header on to the XMPP recipient.
4.2.5. Message Subject
The ’Subject’ header of a "Message/CPIM" object maps to the
<subject/> child element of an XMPP message stanza. To map the CPIM
’Subject’ header to the XMPP <subject/> element, the gateway SHOULD
simply map the value of the ’Subject’ header to the XML character
data of the XMPP <subject/> element. The ’Subject’ header MAY
specify the "lang" in which the subject is written. If "lang"
information is provided, it MUST be mapped to the ’xml:lang’
attribute of the <subject/> element, where the value of the
’xml:lang’ attribute is the "tag" value supplied in the string
’;lang=tag’ included after the CPIM ’Subject’ header name and colon.
Example: Subject Mapping
CPIM ’Subject’ header
Subject: Hi!
Subject:;lang=cz Ahoj!
XMPP <subject/> element
<subject>Hi!</subject>
<subject xml:lang=’cz’>Ahoj!</subject>
4.2.6. Header Extensions
"Message/CPIM" objects MAY include an optional ’NS’ header to specify
the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT
pass such headers through to the XMPP recipient, and no mapping for
such headers is defined.
4.2.7. Require Header
"Message/CPIM" objects MAY include an optional ’Require’ header to
specify mandatory-to-recognize features. In general, such a header
would be included by the non-XMPP sending application to (1) insist
that the receiving application needs to understand functionality
specified by a particular header or (2) indicate that some non-header
semantics need to be implemented by the receiving application in
order to understand the contents of the message (e.g.,
"Locale.MustRenderKanji"). Because the mandatory-to-recognize
features would be required of the XMPP receiving application rather
than the XMPP-CPIM gateway itself, the gateway cannot properly handle
the ’Require’ header without detailed knowledge about the
capabilities of the XMPP receiving application. Therefore, it seems
appropriate that the XMPP-CPIM gateway SHOULD return a warning or
error to the non-XMPP sending application if it includes one or more
’Require’ headers in a "Message/CPIM" object; the exact nature of the
warning or error will depend on the nature of the non-XMPP technology
used by the foreign system, and is not defined herein. Furthermore,
any mapping of the ’Require’ header into XMPP or an XMPP extension is
left up to the implementation or to a future specification.
4.2.8. MIME Content-ID
XMPP does not include an element or attribute that captures a
globally unique ID as is defined for the Content-ID MIME header as
specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object
that includes a Content-ID, it MAY provide the Content-ID as the
value of the message stanza’s ’id’ attribute, but this is OPTIONAL.
Example: Content-ID for Encapsulated Object
MIME header
Content-ID: <123456789@example.net>
XMPP ’id’ attribute (OPTIONAL)
<message id=’123456789@example.net’>
...
</message>
4.2.9. Message Body
If the Content-type of an encapsulated MIME object is "text/plain",
then the encapsulated text message content maps to the XML character
data of the <body/> child element of an XMPP message stanza.
Example: Message Body
Encapsulated MIME text content
Content-type: text/plain; charset=utf-8
Content-ID: <123456789@example.net>
Wherefore art thou?
XMPP message <body/>
<message id=’123456789@example.net’>
<body>Wherefore art thou?</body>
</message>
If the Content-Type is not "text/plain", the XMPP-CPIM gateway MAY
map the content to an XMPP extension but MUST NOT map it to the
<body/> child of the XMPP message stanza, which is allowed to contain
XML character data only. The only exception to this rule is a
multi-part MIME object of the kind specified in [XMPP-E2E], which is
to be mapped as described in that memo.
If the charset is "US-ASCII" or "UTF-8", the gateway MUST map the
"Message/CPIM" object; otherwise it SHOULD NOT.
4.2.10. Gateway-Generated XMPP Syntax
XMPP specifies the existence of a ’type’ attribute for XMPP message
stanzas, which enables the sender to define the conversational
context of the message. There is no exact analogue for this
attribute in CPIM. An XMPP-CPIM gateway MAY independently generate
the ’type’ attribute based on its own information, but this is
OPTIONAL and rules for doing so are out of scope for this memo.
5. Syntax Mapping of Presence Information
This section describes how a gateway SHOULD map presence information
between an XMPP service and a non-XMPP service using a "Message/CPIM"
object as the bearer of an encapsulated [PIDF] object in order to
comply with the presence semantics defined by [CPP].
5.1. Presence Syntax Mapping from XMPP to CPIM Specifications
This section defines the mapping of syntax primitives from XMPP
presence stanzas to "Message/CPIM" objects with encapsulated
"application/pidf+xml" objects.
Note: As specified in [MIME], the default Content-type of a MIME
object is "Content-type: text/plain; charset=us-ascii". Because XMPP
uses the [UTF-8] character encoding exclusively and because PIDF
specifies the "application/pidf+xml" MIME type, the encapsulated MIME
object generated by an XMPP-CPIM gateway for presence information
MUST set the ’Content-type’ header for that object. The
"Content-type" MUST be set to "application/pidf+xml" and the charset