Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
Network Working Group P. Saint-Andre
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
Saint-Andre Standards Track [Page 1]
RFC 3922 XMPP to CPIM October 2004
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].
Saint-Andre Standards Track [Page 2]
RFC 3922 XMPP to CPIM October 2004
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
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.
Saint-Andre Standards Track [Page 3]
RFC 3922 XMPP to CPIM October 2004
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]
Saint-Andre Standards Track [Page 4]
RFC 3922 XMPP to CPIM October 2004
5. Combine resulting local-part with mapped hostname to form
local@domain address
6. Prepend with 'im:' scheme (for XMPP stanzas) or
'pres:' scheme (for XMPP 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
Saint-Andre Standards Track [Page 5]
RFC 3922 XMPP to CPIM October 2004
"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
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
. 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
...
CPIM 'From' header
From: Juliet Capulet
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 or
. 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).
Saint-Andre Standards Track [Page 6]
RFC 3922 XMPP to CPIM October 2004
Example: To Address Mapping
XMPP 'to' attribute
...
CPIM 'To' header
To: Romeo Montague
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 child element to
specify the conversation thread in which the message is situated.
There is no mapping of an XMPP 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
child element, the gateway SHOULD ignore the value
provided.
4.1.6. Message Subject
An XMPP message stanza MAY include a child element. If
included, it maps to the 'Subject' header of a "Message/CPIM" object.
To map the XMPP element to the 'Subject' header of a
"Message/CPIM" object, the gateway SHOULD simply map the XML
character data of the XMPP element to the value of the
Saint-Andre Standards Track [Page 7]
RFC 3922 XMPP to CPIM October 2004
'Subject' header. The 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 element
Hi!
Ahoj!
CPIM 'Subject' header
Subject: Hi!
Subject:;lang=cz Ahoj!
4.1.7. Message Body
The
child element of an XMPP message stanza is used to
provide the primary meaning of the message. The XML character data
of the XMPP
element maps to the encapsulated text message
content.
Example: Message Body
XMPP message
Wherefore art thou, Romeo?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. Saint-Andre Standards
Track [Page 8]
RFC 3922 XMPP to CPIM October 2004 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 XMPP 'from' attribute ...
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 Saint-Andre Standards Track [Page 9]
RFC 3922 XMPP to CPIM October 2004 "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 XMPP 'to' attribute ... 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 child element of an XMPP message stanza. To map
the CPIM 'Subject' header to the XMPP element, the gateway SHOULD
simply map the value of the 'Subject' header to the XML character
data of the XMPP 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
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. Saint-Andre Standards Track [Page
10]
RFC 3922 XMPP to CPIM October 2004 Example: Subject Mapping
CPIM 'Subject' header Subject: Hi! Subject:;lang=cz Ahoj! XMPP
element Hi! Ahoj! 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. Saint-Andre
Standards Track [Page 11]
RFC 3922 XMPP to CPIM October 2004
Example: Content-ID for Encapsulated Object MIME header Content-ID:
<123456789@example.net> XMPP 'id' attribute (OPTIONAL) ...
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 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
Wherefore art thou?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 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. Saint-Andre Standards Track [Page 12]
RFC 3922
XMPP to CPIM October 2004 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 MUST be set to
"utf-8". 5.1.1. From Address The 'from' attribute of an XMPP
presence 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 negotiated between client and
server during authenticating and resource binding as defined in
[XMPP-CORE]. Thus an XMPP-CPIM gateway will receive from the
sender's XMPP server a presence stanza containing a "from" address
of the form . To map the 'from' attribute of an XMPP presence
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 ... CPIM 'From' header From: Juliet
Capulet Saint-Andre Standards Track [Page 13]
RFC 3922 XMPP to CPIM
October 2004 In addition, the 'from' attribute of an XMPP presence
stanza maps to the 'entity' attribute of a PIDF root element. To
map the XMPP 'from' attribute to the PIDF 'entity' attribute, the
gateway MUST remove the resource identifier and MUST append the
"pres:" Instant Messaging URI scheme to the front of the address.
Example: From Address Mapping (PIDF) XMPP 'from' attribute ... PIDF
'entity' attribute ... Finally, an XMPP-CPIM gateway SHOULD map the
resource identifier of the XMPP address contained in the XMPP
'from' attribute to the 'id' attribute of the PIDF child element.
Example: Resource Identifier Mapping XMPP 'from' attribute ... PIDF
'id' for ... 5.1.2. To Address The 'to' attribute of an XMPP
presence stanza maps to the 'To' header of a "Message/CPIM" object.
In XMPP, the sender MAY include a 'to' attribute on a presence
stanza, and MUST include it if the presence stanza is intended for
delivery directly to another user (presence stanzas intended for
broadcasting are stamped with a 'to' address by the sender's
server). Thus an XMPP-CPIM gateway will receive from the sender's
XMPP server a presence stanza containing a "to" address of the form
or . To map the 'to' attribute of an XMPP presence stanza to the
'To' header of a "Message/CPIM" object, the gateway MUST remove the
resource Saint-Andre Standards Track [Page 14]
RFC 3922 XMPP to
CPIM October 2004 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 ... CPIM 'To' header To:
Romeo Montague 5.1.3. Stanza ID An XMPP presence 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. 5.1.4. Presence Type An XMPP
presence stanza MAY possess a 'type' attribute. If no 'type'
attribute is included, the presence stanza indicates that the
sender is available; this state maps to the PIDF basic presence
type of OPEN. If the 'type' attribute has a value of "unavailable",
the presence stanza indicates that the sender is no longer
available; this state maps to the PIDF basic presence type of
CLOSED. Thus both the absence of a 'type' attribute and a 'type'
attribute set to a value of "unavailable" correspond to the [CPP]
"notify operation". All other presence types are used to manage
presence subscriptions or probe for current presence; mappings for
these other presence types are defined under XMPP-CPIM Gateway as
Presence Service (Section 6). Example: Available Presence XMPP
available presence PIDF basic presence (OPEN) Saint-Andre Standards
Track [Page 15]
RFC 3922 XMPP to CPIM October 2004 open Example:
Unavailable Presence XMPP unavailable presence PIDF basic presence
(CLOSED) closed 5.1.5. Show Element The child element of an XMPP
presence stanza provides additional information about the sender's
availability. The XML character data of the XMPP element maps to
extended content in PIDF. The defined values of the element are
'away', 'chat', 'dnd', and 'xa'; as soon as values are specified
for extended status states in the 'urn:ietf:params:xml:ns:pidf:im'
namespace, the XMPP values will be mapped to the PIDF values.
Example: Show Element XMPP element away PIDF extended presence
information open Saint-Andre Standards Track [Page 16]
RFC 3922
XMPP to CPIM October 2004 away 5.1.6. Status Element The child
element of an XMPP presence stanza provides a user-defined,
natural-language description of the sender's detailed availability
state. The XMPP element maps to the PIDF child of the PIDF element.
Example: Status Element XMPP element away retired to the chamber
PIDF element open away retired to the chamber 5.1.7. Presence
Priority An XMPP presence stanza MAY contain a child element whose
value is an integer between -128 and +127. The value of this
element MAY be mapped to the 'priority' attribute of the child of
the PIDF element. If the value of the XMPP element is negative, an
XMPP-CPIM gateway MUST NOT map the value. The range of allowable
values for the PIDF 'priority' attribute is any decimal number from
zero to one inclusive, with a maximum of three decimal places. If
an XMPP-CPIM gateway maps these values, it SHOULD treat XMPP 0 as
PIDF priority='0' and XMPP 127 as PIDF priority='1', mapping
intermediate values appropriately so that they are unique (e.g.,
XMPP priority 1 to PIDF priority 0.007, XMPP priority 2 to PIDF
priority 0.015, and Saint-Andre Standards Track [Page 17]
RFC 3922
XMPP to CPIM October 2004 so on up through mapping XMPP priority
126 to PIDF priority 0.992; note that this is an example only, and
that the exact mapping shall be determined by the XMPP-CPIM
gateway). Example: Presence Priority XMPP element 13 PIDF element
... im:juliet@example.com 5.1.8. Presence Extensions As defined in
[XMPP-CORE], an XMPP presence stanza may contain "extended" content
in any namespace in order to supplement or extend the semantics of
the core presence 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.
5.1.9. Gateway-Generated CPIM and PIDF Syntax 5.1.9.1. CPIM Message
Headers 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 presence information (i.e., a non-primary
addressee) o DateTime -- specifies the datetime at which the
presence information was sent o NS -- specifies the namespace of a
feature extension Saint-Andre Standards Track [Page 18]
RFC 3922
XMPP to CPIM October 2004 o Subject -- specifies the subject or
topic of the encapsulated "Message/CPIM" object 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 presence 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. 5.1.9.2.
PIDF Elements PIDF specifies the existence of XML elements in
addition to those described above, but there is no exact analogue
for those XML elements in the core XMPP specifications. These
include: o -- specifies an address (e.g., an im:, tel:, or mailto:
URI) at which one may communicate with the presentity; an XMPP-CPIM
gateway MAY include this element, in which case it SHOULD set its
value to the of the XMPP sender, prepended by the "im:" Instant
Messaging URI scheme. o -- specifies the datetime at which the
presence information was sent; an XMPP-CPIM gateway MAY
independently generate this element based on its own information
(e.g., the datetime at which it received the presence 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.
5.2. Presence Syntax Mapping from CPIM Specifications to XMPP This
section defines the mapping of syntax primitives from
"Message/CPIM" objects with encapsulated "application/pidf+xml"
objects to XMPP presence stanzas. Note: An XMPP-CPIM gateway MUST
NOT map to an XMPP presence stanza a "Message/CPIM" object whose
encapsulated MIME object has a Content-type other than
"application/pidf+xml" (with the exception of multi-part MIME
objects as specified in [XMPP-E2E]). 5.2.1. From Address The 'From'
header of a "Message/CPIM" object maps to the portion of the 'from'
attribute of an XMPP presence stanza, and the 'id' attribute of the
PIDF child element maps to the resource identifier portion XMPP
'from' attribute. Therefore, to map the CPIM and PIDF information
to the XMPP 'from' attribute, the Saint-Andre Standards Track [Page
19]
RFC 3922 XMPP to CPIM October 2004 gateway MUST remove the
"im:" Instant Messaging URI scheme from the front of the address
and MUST remove the CPIM "Formal-name" (if provided) in order to
generate the portion of the XMPP 'from' attribute, then add a '/'
character followed by the value of the PIDF element's 'id'
attribute. Example: From Address Mapping CPIM 'From' header From:
Romeo Montague XMPP 'from' attribute ... Example: Resource
Identifier Mapping XMPP 'from' attribute ... PIDF 'id' for ...
5.2.2. To Address The 'To' header of a "Message/CPIM" object maps
to the 'to' attribute of an XMPP presence 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. Saint-Andre Standards Track [Page 20]
RFC 3922 XMPP to
CPIM October 2004 Example: To Address Mapping CPIM 'To' header To:
Juliet Capulet XMPP 'to' attribute ... 5.2.3. Courtesy Copy The
core XMPP specification does not include syntax for specifying a
"courtesy copy" (non-primary addressee) for a presence stanza.
Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
with encapsulated PIDF object that contains a 'cc' header, it
SHOULD NOT pass the information contained in that header on to the
XMPP recipient. 5.2.4. DateTime Header The core XMPP specification
does not include syntax for specifying the datetime at which a
presence stanza was sent. Therefore, if an XMPP-CPIM gateway
receives a "Message/CPIM" object with encapsulated PIDF object that
contains a 'DateTime' header, it SHOULD NOT pass the information
contained in that header on to the XMPP recipient. 5.2.5. Subject
Header An XMPP presence stanza contains no information that can be
mapped to the 'Subject' header of a "Message/CPIM" object.
Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
with encapsulated PIDF object that contains a 'Subject' header, it
SHOULD NOT pass the information contained in that header on to the
XMPP recipient. 5.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. 5.2.7. Require Header "Message/CPIM" objects MAY include
an optional 'Require' header to specify mandatory-to-recognize
features. An XMPP-CPIM gateway MUST NOT pass such headers through
to the XMPP recipient, and no mapping for such headers is defined.
Saint-Andre Standards Track [Page 21]
RFC 3922 XMPP to CPIM October
2004 5.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 presence 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) ...
5.2.9. Basic Presence Status The basic presence status types
defined in PIDF are OPEN and CLOSED. The PIDF basic presence status
of OPEN maps to an XMPP presence stanza that possesses no 'type'
attribute (indicating default availability). The PIDF basic
presence status of CLOSED maps to an XMPP presence stanza that
possesses a 'type' attribute with a value of "unavailable".
Example: OPEN Presence PIDF basic presence (OPEN) open XMPP
available presence Saint-Andre Standards Track [Page 22]
RFC 3922
XMPP to CPIM October 2004 Example: CLOSED Presence PIDF basic
presence (CLOSED) closed XMPP unavailable presence 5.2.10. Extended
Status Information PIDF documents may contain extended content. As
of this writing there are no pre-defined extended status states
that can be mapped to the defined values of the XMPP element
('away', 'chat', 'dnd', and 'xa'). Once PIDF extensions for such
extended status states are defined within the Internet Standards
Process, a gateway SHOULD map those extensions; however, any such
mapping is out of scope for this memo, since the relevant PIDF
extensions have not yet been defined. Example: Extended Status
Information (provisional) PIDF extended presence information open
busy XMPP element dnd Saint-Andre Standards Track [Page 23]
RFC 3922 XMPP to CPIM October 2004 5.2.11. Note Element A PIDF element
may contain a child that provides a user-defined, natural-language
description of the sender's detailed availability state. The PIDF
element maps to the XMPP element. Example: Note Element PIDF
element open busy Wooing Juliet XMPP element dnd Wooing Juliet A
PIDF document with zero tuples MAY contain one or more elements as
direct children of the PIDF element. There is no mapping of such a
PIDF document to an XMPP presence stanza; an entity on the non-XMPP
side of an XMPP-CPIM gateway SHOULD NOT send such a PIDF document
to an XMPP recipient if possible, and an XMPP-CPIM gateway MUST NOT
map such a PIDF document to an XMPP presence stanza (see Zero
Resources (Section 6.3.2)). 5.2.12. Contact Element A PIDF document
may contain a element specifying the URI of an address at which the
principal can be contacted (e.g., an im:, tel:, or mailto: URI).
The core XMPP specification does not include syntax for specifying
the URI of a contact address, since the contact address is implicit
in the 'from' attribute of the XMPP presence stanza. Therefore, if
an XMPP-CPIM gateway receives a "Message/CPIM" object with
encapsulated PIDF object that contains a Saint-Andre Standards
Track [Page 24]
RFC 3922 XMPP to CPIM October 2004 element, it
SHOULD NOT pass the XML character data of the element on to the
XMPP recipient. (However, see Inclusion of Complete PIDF Document
(Section 5.2.15) below.) Example: PIDF Contact Element PIDF element
... im:romeo@example.net XMPP presence stanza 5.2.13. Presence
Priority The child of the PIDF element MAY possess a 'priority'
attribute whose value is a decimal number between zero and one
(with a maximum of three decimal places). The value of this
attribute MAY be mapped to the child element of an XMPP presence
stanza. An XMPP-CPIM gateway MUST NOT map PIDF priority values to
negative values of the XMPP element. If an XMPP-CPIM gateway maps
these values, it SHOULD treat PIDF priority='0' as XMPP 0 and PIDF
priority='1' as 127, mapping intermediate values appropriately so
that they are unique (e.g., PIDF priorities between 0.001 and 0.007
to XMPP priority 1, PIDF priorities between 0.008 and 0.015 to XMPP
priority 2, and so on up through mapping PIDF priorities between
0.992 and 0.999 to XMPP priority 126; note that this is an example
only, and that the exact mapping shall be determined by the
XMPP-CPIM gateway). 5.2.14. Timestamp Element The core XMPP
specification does not include syntax for specifying the datetime
or timestamp at which a presence stanza was sent. Therefore, if an
XMPP-CPIM gateway receives a "Message/CPIM" object with
encapsulated PIDF object that contains a element, it SHOULD NOT
pass the XML character data of the element on to the XMPP
recipient. Saint-Andre Standards Track [Page 25]
RFC 3922 XMPP to
CPIM October 2004 5.2.15. Inclusion of Complete PIDF Document
Certain PIDF elements do not map to XMPP presence stanza syntax
(e.g., the XML character data of the element). However, an XMPP
client may be able to handle such information by parsing a native
PIDF document. To make this possible, an XMPP-CPIM gateway MAY
include the complete PIDF document as a child element of the
presence stanza, as described in [XMPP-PIDF]. If an XMPP client
does not understand this extended data, it naturally MUST ignore
it. 6. XMPP-CPIM Gateway as Presence Service [CPP] defines
semantics for an abstract presence service. An XMPP-CPIM gateway
MAY function as such a presence service, and if so an XMPP entity
can use defined XMPP syntax to interact with the gateway's presence
service. Because [PIDF] does not specify syntax for semantic
operations such as subscribe, this section defines only the XMPP
interactions with the presence service offered by an XMPP-CPIM
gateway, not the translation of such XMPP syntax into PIDF. (Note:
Detailed information about XMPP presence services can be found in
[XMPP-IM]; as much as possible, an XMPP-CPIM gateway SHOULD
implement the syntax, semantics, and server business rules defined
therein.) 6.1. Requesting a Subscription If an XMPP entity wants to
subscribe to the presence information of a non-XMPP presentity
through an XMPP-CPIM gateway, it MUST send a presence stanza of
type "subscribe" to the target presentity. The syntax mapping is as
follows: o The XMPP 'from' attribute (user@host) MUST be mapped to
the CPP "watcher parameter" field (pres:user@host). The XMPP-CPIM
gateway MUST append the "pres:" Presence URI scheme to the front of
the address. o The XMPP 'to' attribute (user@host) MUST be mapped
to the CPP "target parameter" field (pres:user@host). The XMPP-CPIM
gateway MUST append the "pres:" Presence URI scheme to the front of
the address. o There is no XMPP mapping for the CPP "duration
parameter", since XMPP subscriptions are active until they have
been explicitly "unsubscribed". o The XMPP 'id' attribute SHOULD be
mapped to the CPP "TransID" field. Saint-Andre Standards Track
[Page 26]
RFC 3922 XMPP to CPIM October 2004 If the target
presentity approves the subscription request (through whatever
protocol it uses to interact with the gateway), the XMPP-CPIM
gateway MUST return a presence stanza of type "subscribed" to the
XMPP entity and notify the XMPP entity of the target's current
available presence. Thereafter, until the subscription is
cancelled, the gateway MUST notify the subscribing XMPP entity
every time the target's presence information changes. If the target
presentity denies the subscription request, the XMPP-CPIM gateway
MUST return a presence stanza of type "unsubscribed" to the XMPP
entity and MUST NOT invoke the notify operation. In addition to the
approval and denial cases, one of the following exceptions may
occur: o The target parameter (XMPP "to" address) does not refer to
a valid presentity; if this exception occurs, the XMPP-CPIM gateway
MUST return an stanza error to the XMPP entity. o Access control
rules do not permit the entity to subscribe to the target; if this
exception occurs, the XMPP-CPIM gateway MUST return a stanza error
to the XMPP entity. o There exists a pre-existing subscription or
in-progress subscribe operation between the XMPP entity and the
target presentity; if this exception occurs, the XMPP-CPIM gateway
SHOULD return a stanza error to the XMPP entity. XMPP services
assume that a subscription is active until it is explicitly
terminated. However, non-XMPP services may implement subscriptions
of limited duration, which must be periodically refreshed in order
to mimic the permanence of XMPP subscriptions. Therefore, an
XMPP-to-CPIM gateway may need to send such refreshes to the
non-XMPP entity on behalf of the XMPP entity to that the
subscription does not expire. Whether such refreshes are necessary
depends on the native protocol implemented by the CPIM-aware
non-XMPP service to which the gateway is translating. 6.2.
Receiving a Subscription Request If a non-XMPP presentity wants to
subscribe to the presence information of an XMPP entity through an
XMPP-CPIM gateway, it MUST use whatever protocol it uses to
interact with the gateway in order to request the subscription;
subject to local access rules, the gateway MUST then send a
presence stanza of type "subscribe" to the XMPP entity from the
non-XMPP watcher. The syntax mapping is as follows: Saint-Andre
Standards Track [Page 27]
RFC 3922 XMPP to CPIM October 2004 o The
CPP "watcher parameter" field (pres:user@host) MUST be mapped to
the XMPP 'from' attribute (user@host). The XMPP-CPIM gateway MUST
remove the "pres:" Presence URI scheme from the front of the
address. o The CPP "target parameter" field (pres:user@host) MUST
be mapped to the XMPP 'to' attribute (user@host). The XMPP-CPIM
gateway MUST remove the "pres:" Presence URI scheme from the front
of the address. o There is no XMPP mapping for the CPP "duration
parameter", since XMPP subscriptions are active until they have
been explicitly "unsubscribed". o The CPP "TransID" field SHOULD be
mapped to the XMPP 'id' attribute. If the target XMPP entity
approves the subscription request, it MUST send a presence stanza
of type "subscribed" to the watcher presentity. The XMPP-CPIM
gateway MUST then notify the watcher presentity of the target XMPP
entity's current available presence. Thereafter, until the
subscription is cancelled, the gateway MUST notify the watcher
presentity every time the target's presence information changes. If
the target XMPP entity denies the subscription request, it MUST
send a presence stanza of type "unsubscribed" to the watcher
presentity. The XMPP-CPIM gateway MUST NOT invoke the notify
operation. In addition to the approval and denial cases, one of the
following exceptions MAY occur: o The target parameter (XMPP "to"
address) does not refer to a valid XMPP entity o Access control
rules do not permit the watcher presentity to subscribe to the
target XMPP entity o There exists a pre-existing subscription or
in-progress subscribe operation between the watcher presentity and
the target XMPP entity If any of these exceptions occurs, the
XMPP-CPIM gateway MUST inform the watcher presentity of failure.
Saint-Andre Standards Track [Page 28]
RFC 3922 XMPP to CPIM October
2004 XMPP services assume that a subscription is active until it is
explicitly terminated. With the exception of handling duration
parameters whose value is zero, handling duration parameters will
be highly dependent on the implementation and requirements of the
XMPP-CPIM gateway. Since there are no explicit requirements for
supporting a "duration parameter" specified in either [IMP-MODEL]
or [IMP-REQS], duration parameter mapping is a local issue that
falls outside the scope of this memo. However, an XMPP-CPIM gateway
MAY keep track of the duration parameter if received from an entity
on the non-XMPP service and delete the subscription after that
duration parameter expires. 6.3. The Notify Operation An XMPP-CPIM
gateway invokes the CPP "notify operation" whenever the presence
information associated with an XMPP entity or CPP presentity
changes and there are subscribers to that information on the other
side of the gateway. The syntax mapping for presence information
related to a notify operation is defined under Mapping for Presence
(Section 5). 6.3.1. Multiple Resources Semantically, PIDF contains
the notion of multiple presence "tuples". Normally, a PIDF document
will contain at least one tuple but MAY contain more than one tuple
(or zero tuples, for which see next section). In the terminology of
XMPP, each tuple would map to presence information for a separate
resource. However, XMPP does not include the ability to send
presence information about more than one resource at a time, since
the resource that generates the presence information is contained
in the 'from' address of a presence stanza. Therefore, an XMPP-CPIM
gateway that acts as a presence service SHOULD split a PIDF
document that contains multiple tuples into multiple XMPP presence
stanzas, and SHOULD generate only one PIDF document (with multiple
tuples) if an XMPP user currently has multiple connected resources.
In the interest of not multiplying XMPP stanzas beyond necessity,
an XMPP-CPIM gateway SHOULD generate an XMPP presence stanza only
if the presence information contained in a PIDF tuple communicates
a change in the availability status of the device or application
associated with that tuple ID. In the interest of complying with
the PIDF recommendation to provide information about multiple
"resources" in multiple tuples rather than in multiple PIDF
documents, an XMPP-CPIM gateway SHOULD include Saint-Andre
Standards Track [Page 29]
RFC 3922 XMPP to CPIM October 2004
information about all of an XMPP user's resources in one PIDF
document (with one tuple for each resource), even if the
availability status of only one resource has changed. 6.3.2. Zero
Resources A PIDF document may contain zero tuples. For example:
PIDF Document with Zero Tuples Because (1) the 'entity' attribute
of a PIDF element maps to the portion of an XMPP address and (2)
the 'id' attribute of a PIDF element maps to the resource
identifier portion of an XMPP address, a PIDF document that
contains zero tuples would provide presence information about a
rather than a when mapped to XMPP. Although the notion of presence
notifications about a mere user rather than one of the user's
resources is nearly meaningless in the XMPP context, an XMPP-CPIM
gateway SHOULD map a PIDF document with zero tuples to an XMPP
presence stanza whose 'from' address is the user@host of the
non-XMPP entity. However, an XMPP-CPIM gateway MUST NOT generate a
PIDF document with zero children when receiving a presence stanza
from an XMPP entity (i.e., all PIDF documents communicated by the
gateway to a non-XMPP service MUST contain at least one element).
6.4. Unsubscribing If an XMPP entity wants to unsubscribe from the
presence of a non-XMPP presentity through an XMPP-CPIM gateway, it
MUST send a presence stanza of type "unsubscribe" to the target
presentity. The syntax mapping is as follows: o The XMPP 'from'
attribute (user@host) MUST be mapped to the CPP "watcher parameter"
field (pres:user@host). The XMPP-CPIM gateway MUST append the
"pres:" Presence URI scheme to the front of the address. o The XMPP
'to' attribute (user@host) MUST be mapped to the CPP "target
parameter" field (pres:user@host). The XMPP-CPIM gateway MUST
append the "pres:" Presence URI scheme to the front of the address.
o The CPP "duration parameter" MUST be set to zero. Saint-Andre
Standards Track [Page 30]
RFC 3922 XMPP to CPIM October 2004 o The
XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" field. If
the target parameter (XMPP "to" address) does not refer to a valid
presentity, the XMPP-CPIM gateway MUST return an stanza error to
the XMPP entity. Upon receiving the presence stanza of type
"unsubscribe" from the XMPP entity, the XMPP-CPIM gateway MUST NOT
send further presence notifications to the XMPP entity. 6.5.
Cancelling a Subscription If an XMPP entity wants to cancel a
non-XMPP presentity's subscription to the entity's presence through
an XMPP-CPIM gateway, it MUST send a presence stanza of type
"unsubscribed" to the target presentity. The syntax mapping is as
follows: o The XMPP 'from' attribute (user@host) MUST be mapped to
the CPP "watcher parameter" field (pres:user@host). The XMPP-CPIM
gateway MUST add the "pres:" Presence URI scheme to the front of
the address. o The XMPP 'to' attribute (user@host) MUST be mapped
to the CPP "target parameter" field (pres:user@host). The XMPP-CPIM
gateway MUST add the "pres:" Presence URI scheme to the front of
the address. o The CPP "duration parameter" MUST be set to zero. o
The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
field. Upon receiving the presence stanza of type "unsubscribed"
from the XMPP entity, the XMPP-CPIM gateway MUST NOT send further
presence notifications to the watcher presentity. 7. Security
Considerations Detailed security considerations for instant
messaging and presence protocols are given in [IMP-REQS],
specifically in Sections 5.1 through 5.4. This document specifies
methods for exchanging instant messages and presence information
through a gateway that implements [CPIM] and [CPP]. Such a gateway
MUST be compliant with the minimum security requirements of the
instant messaging and presence protocols with which it interfaces.
The introduction of gateways to the security model of instant
messaging and presence in
RFC 2779 also introduces Saint-Andre
Standards Track [Page 31]
RFC 3922 XMPP to CPIM October 2004 some
new risks. In particular, end-to-end security properties
(especially confidentiality and integrity) between instant
messaging and presence user agents that interface through an
XMPP-CPIM gateway can be provided only if common formats are
supported; these formats are specified fully in [XMPP-E2E]. 8.
References 8.1. Normative References [CPIM] Peterson, J., "Common
Profile for Instant Messaging (CPIM)",
RFC 3860, August 2004. [CPP]
Peterson, J., "Common Profile for Presence (CPP)",
RFC 3859, August
2004. [IMP-MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model
for Presence and Instant Messaging",
RFC 2778, February 2000.
[IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent,
"Instant Messaging / Presence Protocol Requirements",
RFC 2779,
February 2000. [MIME] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies",
RFC 2045, November 1996. [MSGFMT] Klyne, G. and D.
Atkins, "Common Presence and Instant Messaging (CPIM): Message
Format",
RFC 3862, August 2004. [PIDF] Sugano, H., Fujimoto, S.,
Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence
Information Data Format (PIDF)",
RFC 3863, August 2004.
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings (stringprep)",
RFC 3454, December 2002.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14,
RFC 2119, March 1997. [URL-GUIDE]
Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
"Guidelines for new URL Schemes",
RFC 2718, November 1999.
Saint-Andre Standards Track [Page 32]
RFC 3922 XMPP to CPIM October
2004 [US-ASCII] Cerf, V., "ASCII format for network interchange",
RFC 20, October 1969. [UTF-8] Yergeau, F., "UTF-8, a transformation
format of ISO 10646", STD 63,
RFC 3629, November 2003. [XMPP-CORE]
Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol
(XMPP): Core",
RFC 3920, October 2004. [XMPP-E2E] Saint-Andre, P.,
Ed., "End-to-End Signing and Object Encryption in the Extensible
Messaging and Presence Protocol (XMPP)",
RFC 3923, October 2004.
[XMPP-IM] Saint-Andre (ed.), P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 3921, October
2004. 8.2. Informative References [RFC2822] Resnick, P., Ed.,
"Internet Message Format",
RFC 2822, April 2001. [MIMETYPES] Freed,
N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME)
Part Two: Media Types",
RFC 2046, November 1996. [XMPP-PIDF]
Saint-Andre, P., "Transporting Presence Information Data/Format
(PIDF) over the Extensible Messaging and Presence Protocol (XMPP)",
Work in Progress, February 2004. Author's Address Peter Saint-Andre
Jabber Software Foundation EMail: stpeter@jabber.org Saint-Andre
Standards Track [Page 33]
RFC 3922 XMPP to CPIM October 2004 Full
Copyright Statement Copyright (C) The Internet Society (2004). This
document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights. This document and the information
contained herein are provided on an "AS IS" basis and THE
CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY
(IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual
Property The IETF takes no position regarding the validity or scope
of any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license under
such rights might or might not be available; nor does it represent
that it has made any independent effort to identify any such
rights. Information on the IETF's procedures with respect to rights
in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR
disclosures made to the IETF Secretariat and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. The IETF invites any interested party to
bring to its attention any copyrights, patents or patent
applications, or other proprietary rights that may cover technology
that may be required to implement this standard. Please address the
information to the IETF at ietf- ipr@ietf.org. Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society. Saint-Andre Standards Track [Page 34]