draft-ietf-xmpp-cpim-02.txt   draft-ietf-xmpp-cpim-03.txt 
Network Working Group P. Saint-Andre XMPP Working Group P. Saint-Andre
Internet-Draft Jabber Software Foundation Internet-Draft Jabber Software Foundation
Expires: February 20, 2004 T. Bamonti Expires: May 20, 2004 November 20, 2003
Jabber, Inc.
August 22, 2003
XMPP CPIM Mapping Mapping the Extensible Messaging and Presence Protocol (XMPP) to
draft-ietf-xmpp-cpim-02 Common Presence and Instant Messaging (CPIM)
draft-ietf-xmpp-cpim-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 20, 2004. This Internet-Draft will expire on May 20, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes a mapping of the Extensible Messaging and This memo describes a mapping of the Extensible Messaging and
Presence Protocol (XMPP) to the Common Presence and Instant Messaging Presence Protocol (XMPP) to the Common Presence and Instant Messaging
(CPIM) specifications. (CPIM) specifications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Mapping of Instant Messages . . . . . . . . . . . . . . . . . 5
1.3 Conventions Used in this Document . . . . . . . . . . . . 5 4. Mapping of Presence . . . . . . . . . . . . . . . . . . . . . 13
1.4 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 5 5. XMPP-CPIM Gateway as Presence Service . . . . . . . . . . . . 26
1.5 Intellectual Property Notice . . . . . . . . . . . . . . . 5 6. Internationalization Considerations . . . . . . . . . . . . . 31
2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
3. Mapping of Instant Messages . . . . . . . . . . . . . . . 7 Normative References . . . . . . . . . . . . . . . . . . . . . 32
3.1 Identification of Instant Inboxes . . . . . . . . . . . . 7 Informative References . . . . . . . . . . . . . . . . . . . . 33
3.2 Message Syntax Mapping from XMPP to CPIM Specifications . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1 From Address . . . . . . . . . . . . . . . . . . . . . . . 7 A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.2 To Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 35
3.2.3 CPIM Courtesy Copy . . . . . . . . . . . . . . . . . . . . 8
3.2.4 XMPP Stanza ID . . . . . . . . . . . . . . . . . . . . . . 8
3.2.5 XMPP Message Type . . . . . . . . . . . . . . . . . . . . 8
3.2.6 XMPP Message Thread . . . . . . . . . . . . . . . . . . . 9
3.2.7 CPIM DateTime Header . . . . . . . . . . . . . . . . . . . 9
3.2.8 Message Subject . . . . . . . . . . . . . . . . . . . . . 9
3.2.9 CPIM Header Extensions . . . . . . . . . . . . . . . . . . 9
3.2.10 CPIM Required Headers . . . . . . . . . . . . . . . . . . 10
3.2.11 MSGFMT MIME Content-type . . . . . . . . . . . . . . . . . 10
3.2.12 MSGFMT MIME Content-ID . . . . . . . . . . . . . . . . . . 10
3.2.13 Message Body . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.14 XMPP Message Extensions . . . . . . . . . . . . . . . . . 11
3.3 Message Syntax Mapping from CPIM Specifications to XMPP . 11
3.3.1 From Address . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2 To Address . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.3 CPIM Courtesy Copy . . . . . . . . . . . . . . . . . . . . 12
3.3.4 XMPP Message Type . . . . . . . . . . . . . . . . . . . . 12
3.3.5 CPIM DateTime Header . . . . . . . . . . . . . . . . . . . 12
3.3.6 Message Subject . . . . . . . . . . . . . . . . . . . . . 12
3.3.7 CPIM Header Extensions . . . . . . . . . . . . . . . . . . 13
3.3.8 CPIM Required Headers . . . . . . . . . . . . . . . . . . 13
3.3.9 MSGFMT MIME Content-type . . . . . . . . . . . . . . . . . 13
3.3.10 MSGFMT MIME Content-ID . . . . . . . . . . . . . . . . . . 13
3.3.11 Message Body . . . . . . . . . . . . . . . . . . . . . . . 14
4. Mapping of Presence . . . . . . . . . . . . . . . . . . . 15
4.1 Identification of Presentities . . . . . . . . . . . . . . 15
4.2 Presence Syntax Mapping from XMPP to CPIM Specifications . 15
4.2.1 From Address . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2 To Address . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3 CPIM Courtesy Copy . . . . . . . . . . . . . . . . . . . . 17
4.2.4 XMPP Stanza ID . . . . . . . . . . . . . . . . . . . . . . 17
4.2.5 CPIM DateTime Header . . . . . . . . . . . . . . . . . . . 17
4.2.6 CPIM Subject Header . . . . . . . . . . . . . . . . . . . 17
4.2.7 CPIM Header Extensions . . . . . . . . . . . . . . . . . . 17
4.2.8 CPIM Required Headers . . . . . . . . . . . . . . . . . . 18
4.2.9 PIDF MIME Content-type . . . . . . . . . . . . . . . . . . 18
4.2.10 PIDF MIME Content-ID . . . . . . . . . . . . . . . . . . . 18
4.2.11 XMPP Presence Type . . . . . . . . . . . . . . . . . . . . 18
4.2.12 XMPP Show Element . . . . . . . . . . . . . . . . . . . . 19
4.2.13 XMPP Status Element . . . . . . . . . . . . . . . . . . . 20
4.2.14 PIDF Contact Element . . . . . . . . . . . . . . . . . . . 21
4.2.15 Presence Priority . . . . . . . . . . . . . . . . . . . . 21
4.2.16 PIDF Timestamp Element . . . . . . . . . . . . . . . . . . 22
4.2.17 XMPP Presence Extensions . . . . . . . . . . . . . . . . . 22
4.3 Presence Syntax Mapping from CPIM Specifications to XMPP . 22
4.3.1 From Address . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2 To Address . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.3 CPIM Courtesy Copy . . . . . . . . . . . . . . . . . . . . 23
4.3.4 CPIM DateTime Header . . . . . . . . . . . . . . . . . . . 23
4.3.5 CPIM Subject Header . . . . . . . . . . . . . . . . . . . 24
4.3.6 CPIM Header Extensions . . . . . . . . . . . . . . . . . . 24
4.3.7 CPIM Required Headers . . . . . . . . . . . . . . . . . . 24
4.3.8 PIDF MIME Content-type . . . . . . . . . . . . . . . . . . 24
4.3.9 PIDF MIME Content-ID . . . . . . . . . . . . . . . . . . . 24
4.3.10 PIDF Basic Presence Status . . . . . . . . . . . . . . . . 25
4.3.11 PIDF Extended Status Information . . . . . . . . . . . . . 26
4.3.12 PIDF Note Element . . . . . . . . . . . . . . . . . . . . 26
4.3.13 PIDF Contact Element . . . . . . . . . . . . . . . . . . . 27
4.3.14 Presence Priority . . . . . . . . . . . . . . . . . . . . 28
4.3.15 PIDF Timestamp Element . . . . . . . . . . . . . . . . . . 28
5. XMPP-CPIM Gateway as Presence Service . . . . . . . . . . 29
5.1 Requesting a Subscription . . . . . . . . . . . . . . . . 29
5.2 Receiving a Subscription Request . . . . . . . . . . . . . 30
5.3 Subscription Durations . . . . . . . . . . . . . . . . . . 31
5.4 The Notify Operation . . . . . . . . . . . . . . . . . . . 31
5.4.1 Multiple Resources . . . . . . . . . . . . . . . . . . . . 32
5.4.2 Zero Resources . . . . . . . . . . . . . . . . . . . . . . 32
5.5 Unsubscribing . . . . . . . . . . . . . . . . . . . . . . 33
5.6 Cancelling a Subscription . . . . . . . . . . . . . . . . 33
6. Mapping of Character Encodings . . . . . . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . 36
Normative References . . . . . . . . . . . . . . . . . . . 37
Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 38
A. Revision History . . . . . . . . . . . . . . . . . . . . . 39
A.1 Changes from draft-ietf-xmpp-cpim-01 . . . . . . . . . . . 39
A.2 Changes from draft-ietf-xmpp-cpim-00 . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . 40
1. Introduction 1. Introduction
1.1 Overview 1.1 Overview
The Instant Messaging and Presence (IMPP) Working Group has defined The Instant Messaging and Presence (IMPP) Working Group has defined
an abstract framework for interoperability among instant messaging an abstract framework for interoperability among instant messaging
(IM) and presence systems that are compliant with RFC 2779 [1]. This (IM) and presence systems that are compliant with [IMP-REQS]. This
framework is commonly called Common Presence and Instant Messaging or framework is commonly called Common Presence and Instant Messaging or
"CPIM". The CPIM specifications include a Common Profile for Instant "CPIM". The CPIM family of specifications include a Common Profile
Messaging [2] (also called CPIM), a Common Profile for Presence [3] for Instant Messaging [CPIM] (also called CPIM), a Common Profile for
(CPP), a CPIM Message Format [4] (MSGFMT), and a Common Presence Presence [CPP], a CPIM Message Format [MSGFMT], and a Common Presence
Information Data Format [5] (PIDF). (Note: to prevent confusion, Information Data Format [PIDF]. (Note: To prevent confusion, Common
Common Presence and Instant Messaging is referred to herein Presence and Instant Messaging is referred to herein collectively as
collectively as "the CPIM specifications", whereas the Common Profile "the CPIM specifications", whereas the Common Profile for Instant
for Instant Messaging is referred to as "CPIM". However, the term Messaging is referred to as "CPIM". In order to refer to a gateway
"XMPP-CPIM Gateway" is used to refer to a gateway between an XMPP between an Extensible Messaging and Presence Protocol (XMPP) service
service and a non-XMPP service, where the common format is defined by and a non-XMPP service where the common format is defined by the CPIM
the CPIM specifications.) specifications, the term "XMPP-CPIM Gateway" is used herein.)
This document describes how the Extensible Messaging and Presence This memo describes how the Extensible Messaging and Presence
Protocol (XMPP Core [6], XMPP IM [7]) maps to the abstract model Protocol ([XMPP-CORE], [XMPP-IM]) maps to the abstract model
contained in the CPIM specifications, mainly for the purpose of contained in the CPIM specifications, mainly for the purpose of
establishing gateways between XMPP services and non-XMPP services establishing gateways between XMPP services and non-XMPP services
that conform to RFC 2779 [1]. Such gateways may be established to that conform to [IMP-REQS]. Such gateways may be established to
interpret the protocols of one service and translate them into the interpret the protocols of one service and translate them into the
protocols of the other service. We can visualize this relationship as protocols of the other service. We can visualize this relationship
follows: as follows:
+-------------+ +-------------+ +------------+ +-------------+ +-------------+ +------------+
| | | | | | | | | | | |
| XMPP | | XMPP-CPIM | | Non-XMPP | | XMPP | | XMPP-CPIM | | Non-XMPP |
| Service | <----> | Gateway | <----> | Service | | Service | <----> | Gateway | <----> | Service |
| | | | | | | | | | | |
+-------------+ +-------------+ +------------+ +-------------+ +-------------+ +------------+
This document defines a mapping for use by a gateway that translates This memo defines a mapping for use by a gateway that translates
between XMPP and a non-XMPP protocol via the CPIM specifications. 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 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 servers (whose native formats may or may not be defined by the CPIM
specifications), but a dedicated translator between XMPP and a specifications), but a dedicated translator between XMPP and a
non-XMPP protocol, where the CPIM specifications define the common non-XMPP protocol, where the CPIM specifications define the common
formats into which the protocols are translated for purposes of formats into which the protocols are translated for purposes of
interworking. interworking.
The mapping defined herein applies to instant messages and presence The mapping defined herein applies to instant messages and presence
information that are not encrypted or signed for end-to-end security. information that are not encrypted or signed for end-to-end security.
For information about secure communications to or from an XMPP For information about secure communications to or from an XMPP
service through an XMPP-CPIM gateway, refer to End-to-End Object service through an XMPP-CPIM gateway, refer to [XMPP-E2E].
Encryption in XMPP [8].
1.2 Terminology 1.2 Terminology
This memo inherits vocabulary defined in RFC 2778 [9]. Terms such as This memo inherits vocabulary defined in [IMP-MODEL]. Terms such as
CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN , PRESENCE SERVICE, CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN , PRESENCE SERVICE,
PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same meaning as PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same meaning as
defined therein. defined therein.
This memo also inherits vocabulary defined in XMPP Core [6]. Terms This memo also inherits vocabulary defined in [XMPP-CORE]. Terms
such as ENTITY, JID, NODE IDENTIFIER, DOMAIN IDENTIFIER, RESOURCE such as ENTITY, NODE IDENTIFIER, DOMAIN IDENTIFIER, RESOURCE
IDENTIFIER, MESSAGE STANZA, and PRESENCE STANZA are used in the same IDENTIFIER, MESSAGE STANZA, and PRESENCE STANZA are used in the same
meaning as defined therein. meaning as defined therein.
1.3 Conventions Used in this Document 1.3 Conventions Used in this Document
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in
2119 [10]. [TERMS].
1.4 Discussion Venue 1.4 Discussion Venue
The authors welcome discussion and comments related to the topics The authors welcome discussion and comments related to the topics
presented in this document. The preferred forum is the presented in this document. The preferred forum is the
<xmppwg@jabber.org> mailing list, for which archives and subscription <xmppwg@jabber.org> mailing list, for which archives and subscription
information are available at <http://www.jabber.org/cgi-bin/mailman/ information are available at <http://www.jabber.org/cgi-bin/mailman/
listinfo/xmppwg/>. listinfo/xmppwg/>.
1.5 Intellectual Property Notice 1.5 Intellectual Property Notice
This document is in full compliance with all provisions of Section 10 This document is in full compliance with all provisions of Section 10
of RFC 2026. Parts of this specification use the term "jabber" for of RFC 2026. Parts of this specification use the term "jabber" for
identifying namespaces and other protocol syntax. Jabber[tm] is a identifying namespaces and other protocol syntax. Jabber[tm] is a
registered trademark of Jabber, Inc. Jabber, Inc. grants permission registered trademark of Jabber, Inc. Jabber, Inc. grants permission
to the IETF for use of the Jabber trademark in association with this to the IETF for use of the Jabber trademark in association with this
specification and its successors, if any. specification and its successors, if any.
1.6 Contributors
Tony Bamonti contributed to the first version of this memo.
2. Approach 2. Approach
XMPP and CPIM are distinctly foreign technologies. Therefore, care XMPP and CPIM are distinctly foreign technologies. Therefore, care
must be taken in mapping between XMPP and the abstract syntax defined must be taken in mapping between XMPP and the abstract syntax defined
by the CPIM specifications. by the CPIM specifications.
At root, XMPP is a data transport protocol for streaming XML At root, XMPP is a data transport protocol for streaming XML elements
fragments (called "stanzas") between any two endpoints on the (called "stanzas") between any two endpoints on the network; message
network; message and presence stanzas are two of the core data and presence stanzas are two of the core data elements defined in
elements defined in XMPP and are often used to exchange instant XMPP and are often used to exchange instant messages and presence
messages and presence information between IM users (although the information between IM users (although the inherent extensibility of
inherent extensibility of XML enables applications to use the general XML enables applications to use the general semantics of these stanza
semantics of these stanza types for other purposes). XMPP is not types for other purposes). XMPP is not based on [MIME]; instead,
based on MIME [11]; instead, XMPP Core [6] defines XML schemas for [XMPP-CORE] defines XML schemas for both message and presence stanzas
both message and presence stanzas (for example, the <body/> child of (for example, the <body/> child of a message stanza contains XML
a message stanza contains XML character data that is usually intended character data that is usually intended to be read by a human user).
to be read by a human user).
The CPIM specifications provide common formats for instant messaging The CPIM specifications provide common formats for instant messaging
and presence through two MIME [11] content-types: "Message/CPIM" for and presence through two [MIME] content-types: "Message/CPIM" for
messages (MSGFMT [4]) and "application/pidf+xml" for presence (PIDF messages ([MSGFMT]) and "application/pidf+xml" for presence ([PIDF]).
[5]). The syntax of "Message/CPIM" objects is similar to but stricter The syntax of "Message/CPIM" objects is similar to but stricter than
than that of RFC 2822 [12], and includes the ability to include that defined in [RFC2822], and provides the ability to include
arbitrary MIME media types [13]. By contrast, each "application/ arbitrary MIME media types [MIMETYPES]. By contrast, each
pidf+xml" object is a complete XML document whose structure is "application/pidf+xml" object is a complete XML document whose
defined by an XML schema. structure is defined by an XML schema.
The approach taken herein is to specify mappings from XMPP elements The approach taken herein is to specify mappings from XMPP elements
and attributes to the headers and MIME formats defined by MSGFMT [4] and attributes to the headers and MIME formats defined by [MSGFMT]
and PIDF [5] in order to comply with the semantics defined by CPIM and [PIDF] in order to comply with the semantics defined by [CPIM]
[2] and CPP [3]. Naturally, mappings in the opposite direction are and [CPP]. Naturally, mappings in the opposite direction are
provided as well. provided as well.
3. Mapping of Instant Messages 3. Mapping of Instant Messages
This section describes how a gateway SHOULD map 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" 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 object as the bearer of encapsulated text content in order to comply
with the instant messaging semantics defined by CPIM [2]. with the instant messaging semantics defined by [CPIM].
3.1 Identification of Instant Inboxes 3.1 Identification of Instant Inboxes
There is a one-to-one relationship between an XMPP entity and a CPIM There is a one-to-one relationship between an XMPP entity and a CPIM
instant inbox when the JID of the entity contains only a node instant inbox when the address of the XMPP entity contains only a
identifier and domain identifier, and the node identifier uniquely node identifier and domain identifier, and the node identifier
corresponds to an IM user who possesses an account on an XMPP server. uniquely corresponds to an IM user who possesses an account on an
However, the syntax for addressing an instant inbox is specified as XMPP server. However, the syntax for addressing an instant inbox is
including the 'im:' URI scheme, whereas an XMPP address does not specified as including the 'im:' URI scheme as defined in [CPIM],
include that scheme, so any mapping between an instant inbox address whereas an XMPP address does not include that scheme, so any mapping
and a JID must add or remove the 'im:' URI scheme as appropriate. between an instant inbox address and an XMPP address must add or
remove the 'im:' URI scheme as appropriate.
3.2 Message Syntax Mapping from XMPP to CPIM Specifications 3.2 Message Syntax Mapping from XMPP to CPIM Specifications
This section defines the mapping of syntax primitives from XMPP This section defines the mapping of syntax primitives from XMPP
message stanzas to "Message/CPIM" objects with encapsulated text message stanzas to "Message/CPIM" objects with encapsulated text
content. content.
3.2.1 From Address 3.2.1 From Address
The 'from' attribute of an XMPP message stanza maps to the 'From' The 'from' attribute of an XMPP message stanza maps to the 'From'
header of a "Message/CPIM" object. In XMPP, the sender MUST NOT header of a "Message/CPIM" object. In XMPP, the sender's server
include a 'from' attribute; instead, the sender's server stamps the stamps or validates the "from" address and sets its value to the full
"from" address and sets its value to the full authzid (including <user@host/resource> negotiated between client and server during
resource identifier) provided by the client when authenticating. Thus authentication and resource binding as defined in [XMPP-CORE]. Thus
an XMPP-CPIM gateway will receive from the sender's XMPP server a an XMPP-CPIM gateway will receive from the sender's XMPP server a
message stanza containing a "from" address of the form <node@domain/ message stanza containing a "from" address of the form <user@host/
resource>. To map the 'from' attribute of an XMPP message stanza to 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 'From' header of a "Message/CPIM" object, the gateway MUST remove
the resource identifier, MUST append the "im:" Instant Messaging URI the resource identifier, MUST append the "im:" Instant Messaging URI
scheme to the front of the address, and MAY include a CPIM scheme to the front of the address, and MAY include a CPIM
"Formal-name" for the sender (if known). "Formal-name" for the sender (if known).
Example: From Address Mapping Example: From Address Mapping
XMPP 'from' attribute XMPP 'from' attribute
<message from='juliet@capulet.com/balcony'> <message from='juliet@example.com/balcony'>
... ...
</message> </message>
CPIM 'From' header CPIM 'From' header
From: Juliet Capulet <im:juliet@capulet.com> From: Juliet Capulet <im:juliet@example.com>
3.2.2 To Address 3.2.2 To Address
The 'to' attribute of an XMPP message stanza maps to the 'To' header 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' of a "Message/CPIM" object. In XMPP, the sender SHOULD include a
attribute on a message stanza, and MUST include it if the message is 'to' attribute on a message stanza, and MUST include it if the
intended for delivery to another user. Thus an XMPP-CPIM gateway will message is intended for delivery to another user. Thus an XMPP-CPIM
receive from the sender's XMPP server a message stanza containing a gateway will receive from the sender's XMPP server a message stanza
"to" address of the form <node@domain> or <node@domain/resource>. To containing a "to" address of the form <user@host> or <user@host/
map the 'to' attribute of an XMPP message stanza to the 'To' header resource>. To map the 'to' attribute of an XMPP message stanza to
of a "Message/CPIM" object, the gateway MUST remove the resource the 'To' header of a "Message/CPIM" object, the gateway MUST remove
identifier (if included), MUST append the "im:" Instant Messaging URI the resource identifier (if included), MUST append the "im:" Instant
scheme to the front of the address, and MAY include a CPIM Messaging URI scheme to the front of the address, and MAY include a
"Formal-name" for the recipient (if known). CPIM "Formal-name" for the recipient (if known).
Example: To Address Mapping Example: To Address Mapping
XMPP 'to' attribute XMPP 'to' attribute
<message to='romeo@montague.net/orchard'> <message to='romeo@example.net/orchard'>
... ...
</message> </message>
CPIM 'To' header CPIM 'To' header
To: Romeo Montague <im:romeo@montague.net> To: Romeo Montague <im:romeo@example.net>
3.2.3 CPIM Courtesy Copy 3.2.3 CPIM Courtesy Copy
The core XMPP specification does not include syntax for specifying a The core XMPP specification does not include syntax for specifying a
"courtesy copy" (non-primary addressee) for a message stanza. "courtesy copy" (non-primary addressee) for a message stanza.
Therefore, an XMPP-CPIM gateway MUST NOT generate the 'cc' header of Therefore, an XMPP-CPIM gateway SHOULD NOT generate the 'cc' header
a "Message/CPIM" object. of a "Message/CPIM" object.
3.2.4 XMPP Stanza ID 3.2.4 XMPP Stanza ID
An XMPP message stanza MAY possess an 'id' attribute, which is used An XMPP message stanza MAY possess an 'id' attribute, which is used
by the sending application for the purpose of tracking stanzas. There by the sending application for the purpose of tracking stanzas.
is no mapping of an XMPP 'id' attribute to a "Message/CPIM" header, There is no mapping of an XMPP 'id' attribute to a "Message/CPIM"
common MIME features, or encapsulated text content. Therefore if an header, common MIME features, or encapsulated text content.
XMPP stanza received by an XMPP-CPIM gateway possesses an 'id' Therefore if an XMPP stanza received by an XMPP-CPIM gateway
attribute, the gateway SHOULD ignore the value provided. possesses an 'id' attribute, the gateway SHOULD ignore the value
provided.
3.2.5 XMPP Message Type 3.2.5 XMPP Message Type
An XMPP message stanza MAY possess a 'type' attribute, which is used An XMPP message stanza MAY possess a 'type' attribute, which is used
by the sending application to capture the conversational context of by the sending application to capture the conversational context of
the message. There is no mapping of an XMPP 'type' attribute to a the message. There is no mapping of an XMPP 'type' attribute to a
"Message/CPIM" header, common MIME features, or encapsulated text "Message/CPIM" header, common MIME features, or encapsulated text
content. Therefore if an XMPP stanza received by an XMPP-CPIM gateway content. Therefore if an XMPP stanza received by an XMPP-CPIM
possesses a 'type' attribute, the gateway SHOULD ignore the value gateway possesses a 'type' attribute, the gateway SHOULD ignore the
provided. value provided.
3.2.6 XMPP Message Thread 3.2.6 XMPP Message Thread
An XMPP message stanza MAY contain a <thread/> child element to An XMPP message stanza MAY contain a <thread/> child element to
specify the conversation thread in which the message is situated. specify the conversation thread in which the message is situated.
There is no mapping of an XMPP <thread/> element to a "Message/CPIM" There is no mapping of an XMPP <thread/> element to a "Message/CPIM"
header, common MIME features, or encapsulated text content. Therefore header, common MIME features, or encapsulated text content.
if an XMPP message stanza received by an XMPP-CPIM gateway contains a Therefore if an XMPP message stanza received by an XMPP-CPIM gateway
<thread/> child element, the gateway SHOULD ignore the value contains a <thread/> child element, the gateway SHOULD ignore the
provided. value provided.
3.2.7 CPIM DateTime Header 3.2.7 CPIM DateTime Header
The core XMPP specification does not include syntax for specifying The core XMPP specification does not include syntax for specifying
the datetime at which a message stanza was sent. However, an the datetime at which a message stanza was sent. However, an
XMPP-CPIM gateway MAY include a 'DateTime' header in the "Message/ XMPP-CPIM gateway MAY include a 'DateTime' header in the "Message/
CPIM" object it generates, the value of which SHOULD be the datetime CPIM" object it generates, the value of which SHOULD be the datetime
at which the message stanza was received for processing by the at which the message stanza was received for processing by the
gateway. gateway.
3.2.8 Message Subject 3.2.8 Message Subject
An XMPP message stanza MAY include a <subject/> child element. If An XMPP message stanza MAY include a <subject/> child element. If
included, it maps to the 'Subject' header of a "Message/CPIM" object. included, it maps to the 'Subject' header of a "Message/CPIM" object.
The <subject/> element MAY include an 'xml:lang' attribute specifying To map the XMPP <subject/> element to the 'Subject' header of a
the language in which the subject is written. To map the XMPP "Message/CPIM" object, the gateway SHOULD simply map the XML
<subject/> element to the 'Subject' header of a "Message/CPIM" character data of the XMPP <subject/> element to the value of the
object, the gateway SHOULD simply map the XMPP CDATA to the value of 'Subject' header. The <subject/> element MAY include an 'xml:lang'
the 'Subject' header. If an 'xml:lang' attribute is provided, it MUST attribute specifying the language in which the subject is written.
be mapped by including ';lang=tag' after the header name and colon, If an 'xml:lang' attribute is provided, it MUST be mapped by
where 'tag' is the value of the 'xml:lang' attribute. including ';lang=tag' after the header name and colon, where 'tag' is
the value of the 'xml:lang' attribute.
Example: Subject Mapping Example: Subject Mapping
XMPP <subject/> element XMPP <subject/> element
<subject>Hi!</subject> <subject>Hi!</subject>
<subject xml:lang='cz'>Ahoj!</subject> <subject xml:lang='cz'>Ahoj!</subject>
CPIM 'Subject' header CPIM 'Subject' header
Subject: Hi! Subject: Hi!
Subject:;lang=cz Ahoj! Subject:;lang=cz Ahoj!
skipping to change at page 10, line 15 skipping to change at page 8, line 42
SHOULD NOT generate such headers. SHOULD NOT generate such headers.
3.2.10 CPIM Required Headers 3.2.10 CPIM Required Headers
A "Message/CPIM" object MAY include an optional 'Required' header to A "Message/CPIM" object MAY include an optional 'Required' header to
specify mandatory-to-recognize features. An XMPP-CPIM gateway SHOULD specify mandatory-to-recognize features. An XMPP-CPIM gateway SHOULD
NOT generate such headers. NOT generate such headers.
3.2.11 MSGFMT MIME Content-type 3.2.11 MSGFMT MIME Content-type
RFC 2045 [11] specifies that the default Content-type of a MIME As specified in [MIME], the default Content-type of a MIME object is
object is "Content-type: text/plain; charset=us-ascii". Because XMPP "Content-type: text/plain; charset=us-ascii". Because XMPP uses the
uses a different character encoding (either UTF-8 or UTF-16 depending [UTF-8] character encoding exclusively, the encapsulated MIME object
on stream negotiation), the encapsulated MIME object generated by an generated by an XMPP-CPIM gateway MUST set the 'Content-type' header
XMPP-CPIM gateway MUST set the 'Content-type' header for that object. for that object. The "Content-type" MUST be set to "text/plain" and
The "Content-type" MUST be set to "text/plain" and the charset MUST the charset MUST be set to UTF-8.
be set to the character encoding negotiated for the XML stream used
by the sender, i.e., either UTF-8 or UTF-16.
Example: Content-type for Encapsulated Object Example: Content-type for Encapsulated Object
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
3.2.12 MSGFMT MIME Content-ID 3.2.12 MSGFMT MIME Content-ID
RFC 2045 [11] specifies that the Content-ID is OPTIONAL for MIME As specified in [MIME], the Content-ID is OPTIONAL for MIME objects.
objects. While an XMPP-CPIM gateway MAY generate a Content-ID for While an XMPP-CPIM gateway MAY generate a Content-ID for encapsulated
encapsulated MIME objects, it is NOT REQUIRED to do so. If included, MIME objects, it is NOT REQUIRED to do so. If included, Content-ID
Content-ID values MUST be generated to be world-unique. values MUST be generated to be world-unique.
Example: Content-ID for Encapsulated Object Example: Content-ID for Encapsulated Object
Content-ID: <123456789@montague.net> Content-ID: <123456789@example.net>
3.2.13 Message Body 3.2.13 Message Body
The <body/> child element of an XMPP message stanza is used to The <body/> child element of an XMPP message stanza is used to
provide the primary meaning of the message. The CDATA of the XMPP provide the primary meaning of the message. The XML character data
<body/> element maps to the encapsulated text message content. of the XMPP <body/> element maps to the encapsulated text message
content.
Example: Message Body Example: Message Body
XMPP message <body/> XMPP message <body/>
<message> <message>
<body>Wherefore art thou, Romeo?</body> <body>Wherefore art thou, Romeo?</body>
</message> </message>
Encapsulated MIME text content Encapsulated MIME text content
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
Content-ID: <123456789@montague.net> Content-ID: <123456789@example.net>
Wherefore art thou, Romeo? Wherefore art thou, Romeo?
3.2.14 XMPP Message Extensions 3.2.14 XMPP Message Extensions
As defined in XMPP Core [6], an XMPP message stanza may contain As defined in [XMPP-CORE], an XMPP message stanza may contain
"extended" content in any namespace in order to supplement or extend "extended" content in any namespace in order to supplement or extend
the semantics of the core message stanza. With the exception of the semantics of the core message stanza. With the exception of
extended information qualified by the extended information qualified by the
'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in End-to-End 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in [XMPP-E2E],
Object Encryption in XMPP [8], an XMPP-CPIM gateway SHOULD ignore an XMPP-CPIM gateway SHOULD ignore such information and not pass it
such information and not pass it through the gateway to the intended through the gateway to the intended recipient. No mapping for such
recipient. No mapping for such information is defined. information is defined.
3.3 Message Syntax Mapping from CPIM Specifications to XMPP 3.3 Message Syntax Mapping from CPIM Specifications to XMPP
This section defines the mapping of syntax primitives from "Message/ This section defines the mapping of syntax primitives from "Message/
CPIM" objects with encapsualted text content to XMPP message stanzas. CPIM" objects with encapsualted text content to XMPP message stanzas.
3.3.1 From Address 3.3.1 From Address
The 'From' header of a "Message/CPIM" object maps to the 'from' 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 attribute of an XMPP message stanza. To map the CPIM 'From' header
the XMPP 'from' attribute, the gateway MUST remove the "im:" Instant to the XMPP 'from' attribute, the gateway MUST remove the "im:"
Messaging URI scheme from the front of the address and MUST remove Instant Messaging URI scheme from the front of the address and MUST
the CPIM "Formal-name" (if provided). remove the CPIM "Formal-name" (if provided).
Example: From Address Mapping Example: From Address Mapping
CPIM 'From' header CPIM 'From' header
From: Romeo Montague <im:romeo@montague.net> From: Romeo Montague <im:romeo@example.net>
XMPP 'from' attribute XMPP 'from' attribute
<message from='romeo@montague.net'> <message from='romeo@example.net'>
... ...
</message> </message>
3.3.2 To Address 3.3.2 To Address
The 'To' header of a "Message/CPIM" object maps to the 'to' attribute 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 of an XMPP message stanza. To map the CPIM 'To' header to the XMPP
'to' attribute, the gateway MUST remove the "im:" Instant Messaging 'to' attribute, the gateway MUST remove the "im:" Instant Messaging
URI scheme from the front of the address and MUST remove the CPIM URI scheme from the front of the address and MUST remove the CPIM
"Formal-name" (if provided). If the gateway possesses knowledge of "Formal-name" (if provided). If the gateway possesses knowledge of
the resource identifier in use by the XMPP entity, the gateway MAY the resource identifier in use by the XMPP entity, the gateway MAY
append the resource identifier to the address. append the resource identifier to the address.
Example: To Address Mapping Example: To Address Mapping
CPIM 'To' header CPIM 'To' header
To: Juliet Capulet <im:juliet@capulet.com> To: Juliet Capulet <im:juliet@example.com>
XMPP 'to' attribute XMPP 'to' attribute
<message to='juliet@capulet.com/balcony'> <message to='juliet@example.com/balcony'>
... ...
</message> </message>
3.3.3 CPIM Courtesy Copy 3.3.3 CPIM Courtesy Copy
The core XMPP specification does not include syntax for specifying a The core XMPP specification does not include syntax for specifying a
"courtesy copy" (non-primary addressee) for a message stanza. "courtesy copy" (non-primary addressee) for a message stanza.
Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
that contains a 'cc' header, it MUST NOT pass that information on to that contains a 'cc' header, it SHOULD NOT pass that information on
the XMPP recipient. to the XMPP recipient.
3.3.4 XMPP Message Type 3.3.4 XMPP Message Type
MSGFMT does not possess the concept of a message type that can map to MSGFMT does not possess the concept of a message type that can map to
the XMPP 'type' attribute for message stanzas. Therefore an XMPP-CPIM the XMPP 'type' attribute for message stanzas. Therefore an
gateway SHOULD NOT include the 'type' attribute on the messages it XMPP-CPIM gateway SHOULD NOT include the 'type' attribute on the
sends to XMPP recipients. messages it sends to XMPP recipients.
3.3.5 CPIM DateTime Header 3.3.5 CPIM DateTime Header
The core XMPP specification does not include syntax for specifying The core XMPP specification does not include syntax for specifying
the datetime at which a message stanza was sent. Therefore, if an the datetime at which a message stanza was sent. Therefore, if an
XMPP-CPIM gateway receives a "Message/CPIM" object that contains a XMPP-CPIM gateway receives a "Message/CPIM" object that contains a
'DateTime' header, it SHOULD NOT pass that information on to the XMPP 'DateTime' header, it SHOULD NOT pass that information on to the XMPP
recipient. recipient.
3.3.6 Message Subject 3.3.6 Message Subject
The 'Subject' header of a "Message/CPIM" object maps to the <subject/ The 'Subject' header of a "Message/CPIM" object maps to the <subject/
> child element of an XMPP message stanza. The 'Subject' header MAY > child element of an XMPP message stanza. To map the CPIM 'Subject'
specify the "lang" in which the subject is written. To map the CPIM header to the XMPP <subject/> element, the gateway SHOULD simply map
'Subject' header to the XMPP <subject/> element, the gateway SHOULD the value of the 'Subject' header to the XML character data of the
simply map the value of the 'Subject' header to the XMPP CDATA. If XMPP <subject/> element. The 'Subject' header MAY specify the "lang"
"lang" information is provided, it MUST be mapped to the 'xml:lang' in which the subject is written. If "lang" information is provided,
attribute of the <subject/> element, where the value of the it MUST be mapped to the 'xml:lang' attribute of the <subject/>
'xml:lang' attribute is the the "tag" value supplied in the string element, where the value of the 'xml:lang' attribute is the the "tag"
';lang=tag' included CPIM 'Subject' header name and colon. value supplied in the string ';lang=tag' included CPIM 'Subject'
header name and colon.
Example: Subject Mapping Example: Subject Mapping
CPIM 'Subject' header CPIM 'Subject' header
Subject: Hi! Subject: Hi!
Subject:;lang=cz Ahoj! Subject:;lang=cz Ahoj!
XMPP <subject/> element XMPP <subject/> element
<subject>Hi!</subject> <subject>Hi!</subject>
<subject xml:lang='cz'>Ahoj!</subject> <subject xml:lang='cz'>Ahoj!</subject>
skipping to change at page 13, line 26 skipping to change at page 12, line 4
<subject xml:lang='cz'>Ahoj!</subject> <subject xml:lang='cz'>Ahoj!</subject>
3.3.7 CPIM Header Extensions 3.3.7 CPIM Header Extensions
"Message/CPIM" objects MAY include an optional 'NS' header to specify "Message/CPIM" objects MAY include an optional 'NS' header to specify
the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT
pass such headers through to the XMPP recipient, and no mapping for pass such headers through to the XMPP recipient, and no mapping for
such headers is defined. such headers is defined.
3.3.8 CPIM Required Headers 3.3.8 CPIM Required Headers
"Message/CPIM" objects MAY include an optional 'Required' header to "Message/CPIM" objects MAY include an optional 'Required' header to
specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST
NOT pass such headers through to the XMPP recipient, and no mapping NOT pass such headers through to the XMPP recipient, and no mapping
for such headers is defined. for such headers is defined.
3.3.9 MSGFMT MIME Content-type 3.3.9 MSGFMT MIME Content-type
CPIM [4] specifies that a "Message/CPIM" object MAY contain any As specified in [MSGFMT], a "Message/CPIM" object MAY contain any
arbitrary MIME content. However, support for arbitrary content types arbitrary MIME content. However, support for arbitrary content types
is not a requirement in XMPP; in particular, the <body/> child is not a requirement in XMPP; in particular, the <body/> child
element of an XMPP message stanza MUST contain XML character data element of an XMPP message stanza MUST contain XML character data
only. Therefore, an XMPP-CPIM gateway MUST NOT map to an XMPP message only. Therefore, an XMPP-CPIM gateway MUST NOT map to an XMPP
stanza a "Message/CPIM" object whose encapsulated MIME object has a message stanza a "Message/CPIM" object whose encapsulated MIME object
Content-type other than "text/plain" (with the exception of has a Content-type other than "text/plain" (with the exception of
multi-part MIME objects used for End-to-End Object Encryption in XMPP multi-part MIME objects as specified in [XMPP-E2E]).
[8]).
3.3.10 MSGFMT MIME Content-ID 3.3.10 MSGFMT MIME Content-ID
XMPP does not include an element or attribute that captures a XMPP does not include an element or attribute that captures a
globally unique ID as is defined for the Content-ID MIME header as globally unique ID as is defined for the Content-ID MIME header as
specified in RFC 2045 [11]. If an XMPP-CPIM gateway receives a MIME specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object
object that includes a Content-ID, it MAY provide the Content-ID as that includes a Content-ID, it MAY provide the Content-ID as the
the value of the message stanza's 'id' attribute but is NOT REQUIRED value of the message stanza's 'id' attribute but is NOT REQUIRED to
to do so. do so.
Example: Content-ID for Encapsulated Object Example: Content-ID for Encapsulated Object
MIME header MIME header
Content-ID: <123456789@montague.net> Content-ID: <123456789@example.net>
XMPP 'id' attribute (OPTIONAL) XMPP 'id' attribute (OPTIONAL)
<message id='123456789@montague.net'> <message id='123456789@example.net'>
... ...
</message> </message>
3.3.11 Message Body 3.3.11 Message Body
If the Content-type of an encapsulated MIME object is "text/plain", If the Content-type of an encapsulated MIME object is "text/plain",
then the encapsulated text message content maps to the CDATA of the then the encapsulated text message content maps to the XML character
<body/> child element of an XMPP message stanza. data of the <body/> child element of an XMPP message stanza.
Example: Message Body Example: Message Body
Encapsulated MIME text content Encapsulated MIME text content
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
Content-ID: <123456789@montague.net> Content-ID: <123456789@example.net>
Wherefore art thou? Wherefore art thou?
XMPP message <body/> XMPP message <body/>
<message id='123456789@montague.net'> <message id='123456789@example.net'>
<body>Wherefore art thou?</body> <body>Wherefore art thou?</body>
</message> </message>
4. Mapping of Presence 4. Mapping of Presence
This section describes how a gateway SHOULD map 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" between an XMPP service and a non-XMPP service using a "Message/CPIM"
object as the bearer of an encapsulated PIDF [5] object in order to object as the bearer of an encapsulated [PIDF] object in order to
comply with the presence semantics defined by CPP [3]. comply with the presence semantics defined by [CPP].
4.1 Identification of Presentities 4.1 Identification of Presentities
There is a one-to-one relationship between an XMPP entity and a CPP There is a one-to-one relationship between an XMPP entity and a CPP
presentity when the JID of the entity contains only a node identifier presentity when the address of the XMPP entity contains only a node
and domain identifier, and the node identifier uniquely corresponds identifier and domain identifier, and the node identifier uniquely
to an IM user who possesses an account on an XMPP server. However, corresponds to an IM user who possesses an account on an XMPP server.
the syntax of presentities is specified as including the 'pres:' URI However, the syntax of presentities is specified as including the
scheme, whereas XMPP addresses do not include that scheme, so any 'pres:' URI scheme as defined in [CPP], whereas XMPP addresses do not
mapping between presentities and JIDs must add or remove the 'pres:' include that scheme, so any mapping between presentities and XMPP
URI scheme as appropriate. addresses must add or remove the 'pres:' URI scheme as appropriate.
4.2 Presence Syntax Mapping from XMPP to CPIM Specifications 4.2 Presence Syntax Mapping from XMPP to CPIM Specifications
This section defines the mapping of syntax primitives from XMPP This section defines the mapping of syntax primitives from XMPP
presence stanzas to "Message/CPIM" objects with encapsulated presence stanzas to "Message/CPIM" objects with encapsulated
"application/pidf+xml" objects. "application/pidf+xml" objects.
4.2.1 From Address 4.2.1 From Address
The 'from' attribute of an XMPP presence stanza maps to the 'From' The 'from' attribute of an XMPP presence stanza maps to the 'From'
header of a "Message/CPIM" object. In XMPP, the sender MUST NOT header of a "Message/CPIM" object. In XMPP, the sender's server
include a 'from' attribute; instead, the sender's server stamps the stamps or validates the "from" address and sets its value to the
"from" address and sets its value to the full authzid (including <user@host/resource> negotiated between client and server during
resource identifier) provided by the client when authenticating. Thus authenticating and resource binding as defined in [XMPP-CORE]. Thus
an XMPP-CPIM gateway will receive from the sender's XMPP server a an XMPP-CPIM gateway will receive from the sender's XMPP server a
presence stanza containing a "from" address of the form <node@domain/ presence stanza containing a "from" address of the form <user@host/
resource>. To map the 'from' attribute of an XMPP presence stanza to resource>. To map the 'from' attribute of an XMPP presence stanza to
the 'From' header of a "Message/CPIM" object, the gateway MUST remove the 'From' header of a "Message/CPIM" object, the gateway MUST remove
the resource identifier, MUST append the "im:" Instant Messaging URI the resource identifier, MUST append the "im:" Instant Messaging URI
scheme to the front of the address, and MAY include a CPIM scheme to the front of the address, and MAY include a CPIM
"Formal-name" for the sender (if known). "Formal-name" for the sender (if known).
Example: From Address Mapping Example: From Address Mapping
XMPP 'from' attribute XMPP 'from' attribute
<presence from='juliet@capulet.com/balcony'> <presence from='juliet@example.com/balcony'>
... ...
</presence> </presence>
CPIM 'From' header CPIM 'From' header
From: Juliet Capulet <im:juliet@capulet.com> From: Juliet Capulet <im:juliet@example.com>
In addition, the 'from' attribute of an XMPP presence stanza maps to In addition, the 'from' attribute of an XMPP presence stanza maps to
the 'entity' attribute of a PIDF <presence/> root element. To map the the 'entity' attribute of a PIDF <presence/> root element. To map
XMPP 'from' attribute to the PIDF 'entity' attribute, the gateway the XMPP 'from' attribute to the PIDF 'entity' attribute, the gateway
MUST remove the resource identifier and MUST append the "pres:" MUST remove the resource identifier and MUST append the "pres:"
Instant Messaging URI scheme to the front of the address. Instant Messaging URI scheme to the front of the address.
Example: From Address Mapping (PIDF) Example: From Address Mapping (PIDF)
XMPP 'from' attribute XMPP 'from' attribute
<presence from='juliet@capulet.com/balcony'> <presence from='juliet@example.com/balcony'>
... ...
</presence> </presence>
PIDF 'entity' attribute PIDF 'entity' attribute
<presence entity='pres:juliet@capulet.com'> <presence entity='pres:juliet@example.com'>
... ...
</presence> </presence>
Finally, an XMPP-CPIM gateway SHOULD map the resource identifier of Finally, an XMPP-CPIM gateway SHOULD map the resource identifier of
the JID contained in the XMPP 'from' attribute to the 'id' attribute the XMPP address contained in the XMPP 'from' attribute to the 'id'
of the PIDF <tuple/> child element. attribute of the PIDF <tuple/> child element.
Example: Resource Identifier Mapping Example: Resource Identifier Mapping
XMPP 'from' attribute XMPP 'from' attribute
<presence from='juliet@capulet.com/balcony'> <presence from='juliet@example.com/balcony'>
... ...
</presence> </presence>
PIDF 'id' for <tuple/> PIDF 'id' for <tuple/>
<presence entity='pres:juliet@capulet.com'> <presence entity='pres:juliet@example.com'>
<tuple id='balcony'> <tuple id='balcony'>
... ...
</tuple> </tuple>
</presence> </presence>
4.2.2 To Address 4.2.2 To Address
The 'to' attribute of an XMPP presence stanza maps to the 'To' header The 'to' attribute of an XMPP presence stanza maps to the 'To' header
of a "Message/CPIM" object. In XMPP, the sender SHOULD include a 'to' 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 attribute on a presence stanza, and MUST include it if the presence
is intended for delivery to another user. Thus an XMPP-CPIM gateway stanza is intended for delivery directly to another user (presence
will receive from the sender's XMPP server a presence stanza stanzas intended for broadcasting are stamped with a 'to' address by
containing a "to" address of the form <node@domain> or <node@domain/ the sender's server). Thus an XMPP-CPIM gateway will receive from
resource>. To map the 'to' attribute of an XMPP presence stanza to the sender's XMPP server a presence stanza containing a "to" address
the 'To' header of a "Message/CPIM" object, the gateway MUST remove of the form <user@host> or <user@host/resource>. To map the 'to'
the resource identifier (if included), MUST append the "im:" Instant attribute of an XMPP presence stanza to the 'To' header of a
Messaging URI scheme to the front of the address, and MAY include a "Message/CPIM" object, the gateway MUST remove the resource
CPIM "Formal-name" for the recipient (if known). 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 Example: To Address Mapping
XMPP 'to' attribute XMPP 'to' attribute
<presence to='romeo@montague.net/orchard'> <presence to='romeo@example.net/orchard'>
... ...
</presence> </presence>
CPIM 'To' header CPIM 'To' header
To: Romeo Montague <im:romeo@montague.net> To: Romeo Montague <im:romeo@example.net>
4.2.3 CPIM Courtesy Copy 4.2.3 CPIM Courtesy Copy
The core XMPP specification does not include syntax for specifying a The core XMPP specification does not include syntax for specifying a
"courtesy copy" (non-primary addressee) for a presence stanza. "courtesy copy" (non-primary addressee) for a presence stanza.
Therefore, an XMPP-CPIM gateway MUST NOT generate the 'cc' header of Therefore, an XMPP-CPIM gateway SHOULD NOT generate the 'cc' header
a "Message/CPIM" object. of a "Message/CPIM" object.
4.2.4 XMPP Stanza ID 4.2.4 XMPP Stanza ID
An XMPP presence stanza MAY possess an 'id' attribute, which is used An XMPP presence stanza MAY possess an 'id' attribute, which is used
by the sending application for the purpose of tracking stanzas. There by the sending application for the purpose of tracking stanzas.
is no mapping of an XMPP 'id' attribute to a "Message/CPIM" header, There is no mapping of an XMPP 'id' attribute to a "Message/CPIM"
common MIME features, or PIDF elements and attributes. Therefore if header, common MIME features, or PIDF elements and attributes.
an XMPP stanza received by an XMPP-CPIM gateway possesses an 'id' Therefore if an XMPP stanza received by an XMPP-CPIM gateway
attribute, the gateway SHOULD ignore the value provided. possesses an 'id' attribute, the gateway SHOULD ignore the value
provided.
4.2.5 CPIM DateTime Header 4.2.5 CPIM DateTime Header
The core XMPP specification does not include syntax for specifying The core XMPP specification does not include syntax for specifying
the datetime at which a presence stanza was sent. However, an the datetime at which a presence stanza was sent. However, an
XMPP-CPIM gateway MAY include a 'DateTime' header in the "Message/ XMPP-CPIM gateway MAY include a 'DateTime' header in the "Message/
CPIM" object it generates, the value of which SHOULD be the datetime CPIM" object it generates, the value of which SHOULD be the datetime
at which the presence stanza was received for processing by the at which the presence stanza was received for processing by the
gateway. gateway.
skipping to change at page 18, line 16 skipping to change at page 16, line 27
SHOULD NOT generate such headers. SHOULD NOT generate such headers.
4.2.8 CPIM Required Headers 4.2.8 CPIM Required Headers
A "Message/CPIM" object MAY include an optional 'Required' header to A "Message/CPIM" object MAY include an optional 'Required' header to
specify mandatory-to-recognize features. An XMPP-CPIM gateway SHOULD specify mandatory-to-recognize features. An XMPP-CPIM gateway SHOULD
NOT generate such headers. NOT generate such headers.
4.2.9 PIDF MIME Content-type 4.2.9 PIDF MIME Content-type
RFC 2045 [11] specifies that the default Content-type of a MIME As specified in [MIME], the default Content-type of a MIME object is
object is "Content-type: text/plain; charset=us-ascii". Because XMPP "Content-type: text/plain; charset=us-ascii". Because XMPP uses the
uses a different character encoding (either UTF-8 or UTF-16 depending [UTF-8] character encoding exclusively and because PIDF specifies the
on stream negotiation) and because PIDF specifies the "application/ "application/pidf+xml" MIME time, the encapsulated MIME object
pidf+xml" MIME time, the encapsulated MIME object generated by an generated by an XMPP-CPIM gateway for presence information MUST set
XMPP-CPIM gateway for presence information MUST set the the 'Content-type' header for that object. The "Content-type" MUST
'Content-type' header for that object. The "Content-type" MUST be set be set to "application/pidf+xml" and the charset MUST be set to
to "application/pidf+xml" and the charset MUST be set to the UTF-8.
character encoding negotiated for the XML stream used by the sender,
i.e., either UTF-8 or UTF-16.
Example: Content-type for Encapsulated PIDF Object Example: Content-type for Encapsulated PIDF Object
Content-type: application/pidf+xml; charset=utf-8 Content-type: application/pidf+xml; charset=utf-8
4.2.10 PIDF MIME Content-ID 4.2.10 PIDF MIME Content-ID
RFC 2045 [11] specifies that the Content-ID is OPTIONAL for MIME As specified in [MIME], the Content-ID is OPTIONAL for MIME objects.
objects. While an XMPP-CPIM gateway MAY generate a Content-ID for While an XMPP-CPIM gateway MAY generate a Content-ID for encapsulated
encapsulated MIME objects, it is NOT REQUIRED to do so. If included, MIME objects, it is NOT REQUIRED to do so. If included, Content-ID
Content-ID values MUST be generated to be world-unique. values MUST be generated to be world-unique.
Example: Content-ID for Encapsulated Object Example: Content-ID for Encapsulated Object
Content-ID: <123456789@montague.net> Content-ID: <123456789@example.net>
4.2.11 XMPP Presence Type 4.2.11 XMPP Presence Type
An XMPP presence stanza MAY possess a 'type' attribute. If no 'type' An XMPP presence stanza MAY possess a 'type' attribute. If no 'type'
attribute is included, the presence stanza indicates that the sender attribute is included, the presence stanza indicates that the sender
is available; this state maps to the PIDF basic presence type of is available; this state maps to the PIDF basic presence type of
OPEN. If the 'type' attribute has a value of "unavailable", the OPEN. If the 'type' attribute has a value of "unavailable", the
presence stanza indicates that the sender is no longer available; presence stanza indicates that the sender is no longer available;
this state maps to the PIDF basic presence type of CLOSED. Thus both 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 the absence of a 'type' attribute and a 'type' attribute set to a
value of "unavailable" correspond to the CPP [3] "notify operation". value of "unavailable" correspond to the [CPP] "notify operation".
All other presence types are used to manage presence subscriptions or All other presence types are used to manage presence subscriptions or
probe for current presence; mappings for these other presence types probe for current presence; mappings for these other presence types
are defined under XMPP-CPIM Gateway as Presence Service (Section 5). are defined under XMPP-CPIM Gateway as Presence Service (Section 5).
Example: Available Presence Example: Available Presence
XMPP available presence XMPP available presence
<presence from='juliet@capulet.com/balcony'/> <presence from='juliet@example.com/balcony'/>
PIDF basic presence (OPEN) PIDF basic presence (OPEN)
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' <presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:juliet@capulet.com'> entity='pres:juliet@example.com'>
<tuple id='balcony'> <tuple id='balcony'>
<status> <status>
<basic>open</basic> <basic>open</basic>
</status> </status>
</tuple> </tuple>
</presence> </presence>
Example: Unavailable Presence Example: Unavailable Presence
XMPP unavailable presence XMPP unavailable presence
<presence from='juliet@capulet.com/balcony' type='unavailable'/> <presence from='juliet@example.com/balcony' type='unavailable'/>
PIDF basic presence (CLOSED) PIDF basic presence (CLOSED)
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' <presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:romeo@montague.net'> entity='pres:romeo@example.net'>
<tuple id='balcony'> <tuple id='balcony'>
<status> <status>
<basic>closed</basic> <basic>closed</basic>
</status> </status>
</tuple> </tuple>
</presence> </presence>
4.2.12 XMPP Show Element 4.2.12 XMPP Show Element
The <show/> child element of an XMPP presence stanza provides The <show/> child element of an XMPP presence stanza provides
additional information about the sender's availability. The CDATA of additional information about the sender's availability. The XML
the XMPP <show/> element maps to extended <status/> content in PIDF. character data of the XMPP <show/> element maps to extended <status/>
The defined values of the <show/> element are 'away', 'chat', 'dnd', content in PIDF. The defined values of the <show/> element are
and 'xa'; as soon as values are specified for extended status states 'away', 'chat', 'dnd', and 'xa'; as soon as values are specified for
in the 'urn:ietf:params:xml:ns:pidf:im' namespace, the XMPP values extended status states in the 'urn:ietf:params:xml:ns:pidf:im'
will be mapped to the PIDF values. namespace, the XMPP values will be mapped to the PIDF values.
Example: Show Element Example: Show Element
XMPP <show/> element XMPP <show/> element
<presence from='juliet@capulet.com/balcony'> <presence from='juliet@example.com/balcony'>
<show>away</show> <show>away</show>
</presence> </presence>
PIDF extended presence information PIDF extended presence information
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' <presence xmlns='urn:ietf:params:xml:ns:pidf'
xmlns:im='urn:ietf:params:xml:ns:pidf:im' xmlns:im='urn:ietf:params:xml:ns:pidf:im'
entity='pres:juliet@capulet.com'> entity='pres:juliet@example.com'>
<tuple id='balcony'> <tuple id='balcony'>
<status> <status>
<basic>open</basic> <basic>open</basic>
<im:im>away</im:im> <im:im>away</im:im>
</status> </status>
</tuple> </tuple>
</presence> </presence>
4.2.13 XMPP Status Element 4.2.13 XMPP Status Element
The <status/> child element of an XMPP presence stanza provides a The <status/> child element of an XMPP presence stanza provides a
user-defined, natural-language description of the sender's detailed user-defined, natural-language description of the sender's detailed
availability state. The XMPP <status/> element maps to the PIDF availability state. The XMPP <status/> element maps to the PIDF
<note/> child of the PIDF <tuple/> element. <note/> child of the PIDF <tuple/> element.
Example: Status Element Example: Status Element
XMPP <status/> element XMPP <status/> element
<presence from='juliet@capulet.com/balcony'> <presence from='juliet@example.com/balcony'>
<show>away</show> <show>away</show>
<status>retired to the chamber</status> <status>retired to the chamber</status>
</presence> </presence>
PIDF <note/> element PIDF <note/> element
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' <presence xmlns='urn:ietf:params:xml:ns:pidf'
xmlns:im='urn:ietf:params:xml:ns:pidf:im' xmlns:im='urn:ietf:params:xml:ns:pidf:im'
entity='pres:juliet@capulet.com'> entity='pres:juliet@example.com'>
<tuple id='balcony'> <tuple id='balcony'>
<status> <status>
<basic>open</basic> <basic>open</basic>
<im:im>away</im:im> <im:im>away</im:im>
</status> </status>
<note>retired to the chamber</note> <note>retired to the chamber</note>
</tuple> </tuple>
</presence> </presence>
4.2.14 PIDF Contact Element 4.2.14 PIDF Contact Element
The core XMPP specification does not include syntax for specifying The core XMPP specification does not include syntax for specifying
the URL of a contact address, since the contact address is implicit the URL of a contact address, since the contact address is implicit
in the 'from' attribute of the XMPP presence stanza. However, an in the 'from' attribute of the XMPP presence stanza. However, an
XMPP-CPIM gateway MAY include the <contact/> child of the <tuple/> XMPP-CPIM gateway MAY include the <contact/> child of the <tuple/>
element, the value of which SHOULD be the bare JID (<user@domain>) of element, the value of which SHOULD be the <user@host> of the XMPP
the XMPP sender, prepended by the "im:" Instant Messaging URI scheme. sender, prepended by the "im:" Instant Messaging URI scheme.
Example: PIDF Contact Element Example: PIDF Contact Element
XMPP presence stanza XMPP presence stanza
<presence from='juliet@capulet.com/balcony'/> <presence from='juliet@example.com/balcony'/>
PIDF <contact/> element PIDF <contact/> element
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' <presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:juliet@capulet.com'> entity='pres:juliet@example.com'>
<tuple id='balcony'> <tuple id='balcony'>
... ...
<contact>im:juliet@capulet.com</contact> <contact>im:juliet@example.com</contact>
</tuple> </tuple>
</presence> </presence>
4.2.15 Presence Priority 4.2.15 Presence Priority
An XMPP presence stanza MAY contain a <priority/> child element whose An XMPP presence stanza MAY contain a <priority/> child element whose
value is an integer between -128 and +127. The value of this element value is an integer between -128 and +127. The value of this element
MAY be mapped to the 'priority' attribute of the <contact/> child of MAY be mapped to the 'priority' attribute of the <contact/> child of
the PIDF <tuple/> element. If the value of the XMPP <priority/> the PIDF <tuple/> element. If the value of the XMPP <priority/>
element is negative, an XMPP-CPIM gateway MUST NOT map the value. The element is negative, an XMPP-CPIM gateway MUST NOT map the value.
range of allowable values for the PIDF 'priority' attribute is any The range of allowable values for the PIDF 'priority' attribute is
decimal number from zero to one inclusive, with a maximum of three any decimal number from zero to one inclusive, with a maximum of
decimal places. If an XMPP-CPIM gateway maps these values, it SHOULD three decimal places. If an XMPP-CPIM gateway maps these values, it
treat XMPP <priority>0</priority> as PIDF priority='0' and XMPP SHOULD treat XMPP <priority>0</priority> as PIDF priority='0' and
<priority>127</priority> as PIDF priority='1', mapping intermediate XMPP <priority>127</priority> as PIDF priority='1', mapping
values appropriately so that they are unique (e.g., XMPP priority 1 intermediate values appropriately so that they are unique (e.g., XMPP
to PIDF priority 0.007, XMPP priority 2 to PIDF priority 0.015, and priority 1 to PIDF priority 0.007, XMPP priority 2 to PIDF priority
so on up through mapping XMPP priority 126 to PIDF priority 0.992; 0.015, and so on up through mapping XMPP priority 126 to PIDF
note that this is an example only, and that the exact mapping shall priority 0.992; note that this is an example only, and that the exact
be determined by the XMPP-CPIM gateway). mapping shall be determined by the XMPP-CPIM gateway).
Example: Presence Priority Example: Presence Priority
XMPP <status/> element XMPP <status/> element
<presence from='juliet@capulet.com/balcony'> <presence from='juliet@example.com/balcony'>
<priority>13</priority> <priority>13</priority>
</presence> </presence>
PIDF <note/> element PIDF <note/> element
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' <presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:juliet@capulet.com'> entity='pres:juliet@example.com'>
<tuple id='balcony'> <tuple id='balcony'>
... ...
<contact priority='0.102'>im:juliet@capulet.com</contact> <contact priority='0.102'>im:juliet@example.com</contact>
</tuple> </tuple>
</presence> </presence>
4.2.16 PIDF Timestamp Element 4.2.16 PIDF Timestamp Element
The core XMPP specification does not include syntax for specifying The core XMPP specification does not include syntax for specifying
the datetime at which a presence stanza was sent. However, an the datetime at which a presence stanza was sent. However, an
XMPP-CPIM gateway MAY include a <timestamp/> element within the PIDF XMPP-CPIM gateway MAY include a <timestamp/> element within the PIDF
document it generates, the value of which SHOULD be the datetime at document it generates, the value of which SHOULD be the datetime at
which the presence stanza was received for processing by the gateway. which the presence stanza was received for processing by the gateway.
4.2.17 XMPP Presence Extensions 4.2.17 XMPP Presence Extensions
As defined in XMPP Core [6], an XMPP presence stanza may contain As defined in [XMPP-CORE], an XMPP presence stanza may contain
"extended" content in any namespace in order to supplement or extend "extended" content in any namespace in order to supplement or extend
the semantics of the core presence stanza. With the exception of the semantics of the core presence stanza. With the exception of
extended information qualified by the extended information qualified by the
'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in End-to-End 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in [XMPP-E2E],
Object Encryption in XMPP [8], an XMPP-CPIM gateway SHOULD ignore an XMPP-CPIM gateway SHOULD ignore such information and not pass it
such information and not pass it through the gateway to the intended through the gateway to the intended recipient. No mapping for such
recipient. No mapping for such information is defined. information is defined.
4.3 Presence Syntax Mapping from CPIM Specifications to XMPP 4.3 Presence Syntax Mapping from CPIM Specifications to XMPP
This section defines the mapping of syntax primitives from "Message/ This section defines the mapping of syntax primitives from "Message/
CPIM" objects with encapsulated "application/pidf+xml" objects to CPIM" objects with encapsulated "application/pidf+xml" objects to
XMPP presence stanzas. XMPP presence stanzas.
4.3.1 From Address 4.3.1 From Address
The 'From' header of a "Message/CPIM" object maps to the 'from' The 'From' header of a "Message/CPIM" object maps to the 'from'
attribute of an XMPP presence stanza. To map the CPIM 'From' header attribute of an XMPP presence stanza. To map the CPIM 'From' header
to the XMPP 'from' attribute, the gateway MUST remove the "im:" to the XMPP 'from' attribute, the gateway MUST remove the "im:"
Instant Messaging URI scheme from the front of the address and MUST Instant Messaging URI scheme from the front of the address and MUST
remove the CPIM "Formal-name" (if provided). remove the CPIM "Formal-name" (if provided).
Example: From Address Mapping Example: From Address Mapping
CPIM 'From' header CPIM 'From' header
From: Romeo Montague <im:romeo@montague.net> From: Romeo Montague <im:romeo@example.net>
XMPP 'from' attribute XMPP 'from' attribute
<presence from='romeo@montague.net'> <presence from='romeo@example.net'>
... ...
</presence> </presence>
4.3.2 To Address 4.3.2 To Address
The 'To' header of a "Message/CPIM" object maps to the 'to' attribute 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 of an XMPP presence stanza. To map the CPIM 'To' header to the XMPP
'to' attribute, the gateway MUST remove the "im:" Instant Messaging 'to' attribute, the gateway MUST remove the "im:" Instant Messaging
URI scheme from the front of the address and MUST remove the CPIM URI scheme from the front of the address and MUST remove the CPIM
"Formal-name" (if provided). If the gateway possesses knowledge of "Formal-name" (if provided). If the gateway possesses knowledge of
the resource identifier in use by the XMPP entity, the gateway MAY the resource identifier in use by the XMPP entity, the gateway MAY
append the resource identifier to the address. append the resource identifier to the address.
Example: To Address Mapping Example: To Address Mapping
CPIM 'To' header CPIM 'To' header
To: Juliet Capulet <im:juliet@capulet.com> To: Juliet Capulet <im:juliet@example.com>
XMPP 'to' attribute XMPP 'to' attribute
<presence to='juliet@capulet.com/balcony'> <presence to='juliet@example.com/balcony'>
... ...
</presence> </presence>
4.3.3 CPIM Courtesy Copy 4.3.3 CPIM Courtesy Copy
The core XMPP specification does not include syntax for specifying a The core XMPP specification does not include syntax for specifying a
"courtesy copy" (non-primary addressee) for a presence stanza. "courtesy copy" (non-primary addressee) for a presence stanza.
Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
with encapsulated PIDF object that contains a 'cc' header, it MUST with encapsulated PIDF object that contains a 'cc' header, it SHOULD
NOT pass that information on to the XMPP recipient. NOT pass that information on to the XMPP recipient.
4.3.4 CPIM DateTime Header 4.3.4 CPIM DateTime Header
The core XMPP specification does not include syntax for specifying The core XMPP specification does not include syntax for specifying
the datetime at which a presence stanza was sent. Therefore, if an the datetime at which a presence stanza was sent. Therefore, if an
XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
PIDF object that contains a 'DateTime' header, it SHOULD NOT pass PIDF object that contains a 'DateTime' header, it SHOULD NOT pass
that information on to the XMPP recipient. that information on to the XMPP recipient.
skipping to change at page 24, line 29 skipping to change at page 22, line 39
4.3.7 CPIM Required Headers 4.3.7 CPIM Required Headers
"Message/CPIM" objects MAY include an optional 'Required' header to "Message/CPIM" objects MAY include an optional 'Required' header to
specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST
NOT pass such headers through to the XMPP recipient, and no mapping NOT pass such headers through to the XMPP recipient, and no mapping
for such headers is defined. for such headers is defined.
4.3.8 PIDF MIME Content-type 4.3.8 PIDF MIME Content-type
CPIM [4] specifies that a "Message/CPIM" object MAY contain any As specified in [MSGFMT], a "Message/CPIM" object MAY contain any
arbitrary MIME content. However, support for arbitrary content types arbitrary MIME content. However, support for arbitrary content types
is not a requirement in XMPP. An XMPP-CPIM gateway MUST NOT map to an is not a requirement in XMPP. An XMPP-CPIM gateway MUST NOT map to
XMPP presence stanza a "Message/CPIM" object whose encapsulated MIME an XMPP presence stanza a "Message/CPIM" object whose encapsulated
object has a Content-type other than "application/pidf+xml" (with the MIME object has a Content-type other than "application/pidf+xml"
exception of multi-part MIME objects used for End-to-End Object (with the exception of multi-part MIME objects as specified in
Encryption in XMPP [8]). [XMPP-E2E]).
4.3.9 PIDF MIME Content-ID 4.3.9 PIDF MIME Content-ID
XMPP does not include an element or attribute that captures a XMPP does not include an element or attribute that captures a
globally unique ID as is defined for the Content-ID MIME header as globally unique ID as is defined for the Content-ID MIME header as
specified in RFC 2045 [11]. If an XMPP-CPIM gateway receives a MIME specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object
object that includes a Content-ID, it MAY provide the Content-ID as that includes a Content-ID, it MAY provide the Content-ID as the
the value of the presence stanza's 'id' attribute but is NOT REQUIRED value of the presence stanza's 'id' attribute but is NOT REQUIRED to
to do so. do so.
Example: Content-ID for Encapsulated Object Example: Content-ID for Encapsulated Object
MIME header MIME header
Content-ID: <123456789@montague.net> Content-ID: <123456789@example.net>
XMPP 'id' attribute (OPTIONAL) XMPP 'id' attribute (OPTIONAL)
<presence id='123456789@montague.net'> <presence id='123456789@example.net'>
... ...
</presence> </presence>
4.3.10 PIDF Basic Presence Status 4.3.10 PIDF Basic Presence Status
The basic presence status types defined in PIDF are OPEN and CLOSED. The basic presence status types defined in PIDF are OPEN and CLOSED.
The PIDF basic presence status of OPEN maps to an XMPP presence The PIDF basic presence status of OPEN maps to an XMPP presence
stanza that possesses no 'type' attribute (indicating default stanza that possesses no 'type' attribute (indicating default
availability). The PIDF basic presence status of CLOSED maps to an availability). The PIDF basic presence status of CLOSED maps to an
XMPP presence stanza that possesses a 'type' attribute with a value XMPP presence stanza that possesses a 'type' attribute with a value
of "unavailable". of "unavailable".
Example: OPEN Presence Example: OPEN Presence
PIDF basic presence (OPEN) PIDF basic presence (OPEN)
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' <presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:romeo@montague.net'> entity='pres:romeo@example.net'>
<tuple id='orchard'> <tuple id='orchard'>
<status> <status>
<basic>open</basic> <basic>open</basic>
</status> </status>
</tuple> </tuple>
</presence> </presence>
XMPP available presence XMPP available presence
<presence from='romeo@montague.net/orchard'/> <presence from='romeo@example.net/orchard'/>
Example: CLOSED Presence Example: CLOSED Presence
PIDF basic presence (CLOSED) PIDF basic presence (CLOSED)
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' <presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:romeo@montague.net'> entity='pres:romeo@example.net'>
<tuple id='orchard'> <tuple id='orchard'>
<status> <status>
<basic>closed</basic> <basic>closed</basic>
</status> </status>
</tuple> </tuple>
</presence> </presence>
XMPP unavailable presence XMPP unavailable presence
<presence from='romeo@montague.net/orchard' <presence from='romeo@example.net/orchard'
type='unavailable'/> type='unavailable'/>
4.3.11 PIDF Extended Status Information 4.3.11 PIDF Extended Status Information
PIDF documents may contain extended <status/> content. As of this PIDF documents may contain extended <status/> content. As of this
writing there are no pre-defined extended status states that writing there are no pre-defined extended status states that
correspond to the defined values of the XMPP <show/> element ('away', correspond to the defined values of the XMPP <show/> element ('away',
'chat', 'dnd', and 'xa'); as soon as values are specified for 'chat', 'dnd', and 'xa'); as soon as values are specified for
extended status states in the 'urn:ietf:params:xml:ns:pidf:im' extended status states in the 'urn:ietf:params:xml:ns:pidf:im'
namespace, the PIDF values will be mapped to the relevant XMPP namespace, the PIDF values will be mapped to the relevant XMPP
values. values.
Example: Extended Status Information (provisional) Example: Extended Status Information (provisional)
PIDF extended presence information PIDF extended presence information
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' <presence xmlns='urn:ietf:params:xml:ns:pidf'
xmlns:im='urn:ietf:params:xml:ns:pidf:im' xmlns:im='urn:ietf:params:xml:ns:pidf:im'
entity='pres:romeo@montague.net'> entity='pres:romeo@example.net'>
<tuple id='orchard'> <tuple id='orchard'>
<status> <status>
<basic>open</basic> <basic>open</basic>
<im:im>busy</im:im> <im:im>busy</im:im>
</status> </status>
</tuple> </tuple>
</presence> </presence>
XMPP <show/> element XMPP <show/> element
<presence from='romeo@montague.net/orchard'> <presence from='romeo@example.net/orchard'>
<show>dnd</show> <show>dnd</show>
</presence> </presence>
4.3.12 PIDF Note Element 4.3.12 PIDF Note Element
A PIDF <tuple/> element may contain a <note/> child that provides a A PIDF <tuple/> element may contain a <note/> child that provides a
user-defined, natural-language description of the sender's detailed user-defined, natural-language description of the sender's detailed
availability state. The PIDF <note/> element maps to the XMPP availability state. The PIDF <note/> element maps to the XMPP
<status/> element. <status/> element.
Example: Note Element Example: Note Element
PIDF <note/> element PIDF <note/> element
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' <presence xmlns='urn:ietf:params:xml:ns:pidf'
xmlns:im='urn:ietf:params:xml:ns:pidf:im' xmlns:im='urn:ietf:params:xml:ns:pidf:im'
entity='pres:romeo@montague.net'> entity='pres:romeo@example.net'>
<tuple id='orchard'> <tuple id='orchard'>
<status> <status>
<basic>open</basic> <basic>open</basic>
<im:im>busy</im:im> <im:im>busy</im:im>
</status> </status>
<note>Wooing Juliet</note> <note>Wooing Juliet</note>
</tuple> </tuple>
</presence> </presence>
XMPP <status/> element XMPP <status/> element
<presence from='romeo@montague.net/orchard'> <presence from='romeo@example.net/orchard'>
<show>dnd</show> <show>dnd</show>
<status>Wooing Juliet</status> <status>Wooing Juliet</status>
</presence> </presence>
A PIDF document with zero tuples MAY contain one or more <note/> A PIDF document with zero tuples MAY contain one or more <note/>
elements as direct children of the PIDF <presence/> element. There is elements as direct children of the PIDF <presence/> element. There
no mapping of such a PIDF document to an XMPP presence stanza; an 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 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 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 XMPP-CPIM gateway MUST NOT map such a PIDF document to an XMPP
presence stanza (see Zero Resources (Section 5.4.2)). presence stanza (see Zero Resources (Section 5.4.2)).
4.3.13 PIDF Contact Element 4.3.13 PIDF Contact Element
The core XMPP specification does not include syntax for specifying The core XMPP specification does not include syntax for specifying
the URL of a contact address, since the contact address is implicit the URL of a contact address, since the contact address is implicit
in the 'from' attribute of the XMPP presence stanza. Therefore, if an in the 'from' attribute of the XMPP presence stanza. Therefore, if
XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated an XMPP-CPIM gateway receives a "Message/CPIM" object with
PIDF object that contains a <contact/> element, it SHOULD NOT pass encapsulated PIDF object that contains a <contact/> element, it
the CDATA of the <contact/> element on to the XMPP recipient. SHOULD NOT pass the XML character data of the <contact/> element on
However, the gateway MAY map the 'priority' element as specified in to the XMPP recipient. However, the gateway MAY map the 'priority'
the following section. element as specified in the following section.
Example: PIDF Contact Element Example: PIDF Contact Element
PIDF <contact/> element PIDF <contact/> element
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' <presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:romeo@montague.net'> entity='pres:romeo@example.net'>
<tuple id='orchard'> <tuple id='orchard'>
... ...
<contact>im:romeo@montague.net</contact> <contact>im:romeo@example.net</contact>
</tuple> </tuple>
</presence> </presence>
XMPP presence stanza XMPP presence stanza
<presence from='romeo@montague.net/orchard'/> <presence from='romeo@example.net/orchard'/>
4.3.14 Presence Priority 4.3.14 Presence Priority
The <contact/> child of the PIDF <tuple/> element MAY possess a The <contact/> child of the PIDF <tuple/> element MAY possess a
'priority' attribute whose value is a decimal number between zero and 'priority' attribute whose value is a decimal number between zero and
one (with a maximum of three decimal places). The value of this one (with a maximum of three decimal places). The value of this
attribute MAY be mapped to the <priority/> child element of an XMPP attribute MAY be mapped to the <priority/> child element of an XMPP
presence stanza. An XMPP-CPIM gateway MUST NOT map PIDF priority presence stanza. An XMPP-CPIM gateway MUST NOT map PIDF priority
values to negative values of the XMPP <priority/> element. If an values to negative values of the XMPP <priority/> element. If an
XMPP-CPIM gateway maps these values, it SHOULD treat PIDF XMPP-CPIM gateway maps these values, it SHOULD treat PIDF
skipping to change at page 29, line 7 skipping to change at page 26, line 40
4.3.15 PIDF Timestamp Element 4.3.15 PIDF Timestamp Element
The core XMPP specification does not include syntax for specifying The core XMPP specification does not include syntax for specifying
the datetime or timestamp at which a presence stanza was sent. the datetime or timestamp at which a presence stanza was sent.
Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
with encapsulated PIDF object that contains a <timestamp/> element, with encapsulated PIDF object that contains a <timestamp/> element,
it SHOULD NOT pass that information on to the XMPP recipient. it SHOULD NOT pass that information on to the XMPP recipient.
5. XMPP-CPIM Gateway as Presence Service 5. XMPP-CPIM Gateway as Presence Service
CPP [3] defines semantics for an abstract presence service. An [CPP] defines semantics for an abstract presence service. An
XMPP-CPIM gateway MAY function as such a presence service, and if so 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 an XMPP entity can use defined XMPP syntax to interact with the
gateway's presence service. Because PIDF [5] does not specify syntax gateway's presence service. Because [PIDF] does not specify syntax
for semantic operations such as subscribe, this section defines only for semantic operations such as subscribe, this section defines only
the XMPP interactions with the presence service offered by an the XMPP interactions with the presence service offered by an
XMPP-CPIM gateway, not the translation of such XMPP syntax into PIDF. XMPP-CPIM gateway, not the translation of such XMPP syntax into PIDF.
(Note: detailed information about XMPP presence services can be found (Note: Detailed information about XMPP presence services can be found
in XMPP IM [7]; as much as possible, an XMPP-CPIM gateway SHOULD in [XMPP-IM]; as much as possible, an XMPP-CPIM gateway SHOULD
implement the syntax, semantics, and server business rules defined implement the syntax, semantics, and server business rules defined
therein.) therein.)
5.1 Requesting a Subscription 5.1 Requesting a Subscription
If an XMPP entity wants to subscribe to the presence information of a 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 non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
presence stanza of type "subscribe" to the target presentity. The presence stanza of type "subscribe" to the target presentity. The
syntax mapping is as follows: syntax mapping is as follows:
o The XMPP 'from' attribute (node@domain) MUST be mapped to the CPP o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
"watcher parameter" field (pres:node@domain). The XMPP-CPIM "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
gateway MUST append the "pres:" Presence URI scheme to the front MUST append the "pres:" Presence URI scheme to the front of the
of the address. address.
o The XMPP 'to' attribute (node@domain) MUST be mapped to the CPP o The XMPP 'to' attribute (user@host) MUST be mapped to the CPP
"target parameter" field (pres:node@domain). The XMPP-CPIM gateway "target parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST append the "pres:" Presence URI scheme to the front of the MUST append the "pres:" Presence URI scheme to the front of the
address. address.
o There is no XMPP mapping for the CPP "duration parameter", since o There is no XMPP mapping for the CPP "duration parameter", since
XMPP subscriptions are active until they have been explicitly XMPP subscriptions are active until they have been explicitly
"unsubscribed" (see Subscription Durations (Section 5.3)). "unsubscribed" (see Subscription Durations (Section 5.3)).
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
field. field.
skipping to change at page 30, line 33 skipping to change at page 28, line 20
5.2 Receiving a Subscription Request 5.2 Receiving a Subscription Request
If a non-XMPP presentity wants to subscribe to the presence If a non-XMPP presentity wants to subscribe to the presence
information of an XMPP entity through an XMPP-CPIM gateway, it MUST information of an XMPP entity through an XMPP-CPIM gateway, it MUST
use whatever protocol it uses to interact with the gateway in order use whatever protocol it uses to interact with the gateway in order
to request the subscription; subject to local access rules, the to request the subscription; subject to local access rules, the
gateway MUST then send a presence stanza of type "subscribe" to 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 XMPP entity from the non-XMPP watcher. The syntax mapping is as
follows: follows:
o The CPP "watcher parameter" field (pres:node@domain) MUST be o The CPP "watcher parameter" field (pres:user@host) MUST be mapped
mapped to the XMPP 'from' attribute (node@domain). The XMPP-CPIM to the XMPP 'from' attribute (user@host). The XMPP-CPIM gateway
gateway MUST remove the "pres:" Presence URI scheme from the front MUST remove the "pres:" Presence URI scheme from the front of the
of the address. address.
o The CPP "target parameter" field (pres:node@domain) MUST be mapped o The CPP "target parameter" field (pres:user@host) MUST be mapped
to the XMPP 'to' attribute (node@domain). The XMPP-CPIM gateway to the XMPP 'to' attribute (user@host). The XMPP-CPIM gateway
MUST remove the "pres:" Presence URI scheme from the front of the MUST remove the "pres:" Presence URI scheme from the front of the
address. address.
o There is no XMPP mapping for the CPP "duration parameter", since o There is no XMPP mapping for the CPP "duration parameter", since
XMPP subscriptions are active until they have been explicitly XMPP subscriptions are active until they have been explicitly
"unsubscribed" (see Subscription Durations (Section 5.3)). "unsubscribed" (see Subscription Durations (Section 5.3)).
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
field. field.
skipping to change at page 31, line 39 skipping to change at page 29, line 25
If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform
the watcher presentity of failure. the watcher presentity of failure.
5.3 Subscription Durations 5.3 Subscription Durations
XMPP services assume that a subscription is active until it is XMPP services assume that a subscription is active until it is
explicitly terminated. With the exception of handling duration explicitly terminated. With the exception of handling duration
parameters whose value is zero, handling duration parameters will be parameters whose value is zero, handling duration parameters will be
highly dependent on the implementation and requirements of the highly dependent on the implementation and requirements of the
XMPP-CPIM gateway. Since there are no explicit requirements for XMPP-CPIM gateway. Since there are no explicit requirements for
supporting a "duration parameter" specified in either RFC 2778 [9] or supporting a "duration parameter" specified in either [IMP-MODEL] or
RFC 2779 [1], duration parameter mapping is a local issue that falls [IMP-REQS], duration parameter mapping is a local issue that falls
outside the scope of this document. outside the scope of this memo.
5.4 The Notify Operation 5.4 The Notify Operation
An XMPP-CPIM gateway invokes the CPP "notify operation" whenever the An XMPP-CPIM gateway invokes the CPP "notify operation" whenever the
presence information associated with an XMPP entity or CPP presentity presence information associated with an XMPP entity or CPP presentity
changes and there are subscribers to that information on the other changes and there are subscribers to that information on the other
side of the gateway. The syntax mapping for presence information side of the gateway. The syntax mapping for presence information
related to a notify operation is defined under Mapping for Presence related to a notify operation is defined under Mapping for Presence
(Section 4). (Section 4).
skipping to change at page 32, line 40 skipping to change at page 30, line 24
information about all of an XMPP user's resources in one PIDF information about all of an XMPP user's resources in one PIDF
document (with one tuple for each resource), even if the availability document (with one tuple for each resource), even if the availability
status of only one resource has changed. status of only one resource has changed.
5.4.2 Zero Resources 5.4.2 Zero Resources
A PIDF document may contain zero tuples. For example: A PIDF document may contain zero tuples. For example:
PIDF Document with Zero Tuples PIDF Document with Zero Tuples
<presence entity='pres:juliet@capulet.com' <presence entity='pres:juliet@example.com'
xmlns='urn:ietf:params:xml:ns:pidf'/> xmlns='urn:ietf:params:xml:ns:pidf'/>
Because (1) the 'entity' attribute of a PIDF <presence/> element maps Because (1) the 'entity' attribute of a PIDF <presence/> element maps
to the <user@host> portion of an XMPP JID and (2) the 'id' attribute to the <user@host> portion of an XMPP address and (2) the 'id'
of a PIDF <tuple/> element maps to the resource identifier portion of attribute of a PIDF <tuple/> element maps to the resource identifier
an XMPP JID, a PIDF document that contains zero tuples would provide portion of an XMPP address, a PIDF document that contains zero tuples
presence information about a <user@host> rather than a <user@host/ would provide presence information about a <user@host> rather than a
resource> when mapped to XMPP. However, the notion of presence about <user@host/resource> when mapped to XMPP. However, the notion of
a user rather than a user's resources is meaningless in the XMPP presence about a user rather than a user's resources is meaningless
context. Therefore, an XMPP-CPIM gateway MUST NOT map a PIDF document in the XMPP context. Therefore, an XMPP-CPIM gateway MUST NOT map a
with zero tuples into an XMPP presence stanza, and MUST NOT generate PIDF document with zero tuples into an XMPP presence stanza, and MUST
such a PIDF document when receiving a presence stanza from an XMPP NOT generate such a PIDF document when receiving a presence stanza
entity (i.e., all PIDF documents generated by the gateway MUST from an XMPP entity (i.e., all PIDF documents generated by the
contain at least one <tuple/> element). gateway MUST contain at least one <tuple/> element).
5.5 Unsubscribing 5.5 Unsubscribing
If an XMPP entity wants to unsubscribe from the presence of a If an XMPP entity wants to unsubscribe from the presence of a
non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
presence stanza of type "unsubscribe" to the target presentity. The presence stanza of type "unsubscribe" to the target presentity. The
syntax mapping is as follows: syntax mapping is as follows:
o The XMPP 'from' attribute (node@domain) MUST be mapped to the CPP o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
"watcher parameter" field (pres:node@domain). The XMPP-CPIM "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
gateway MUST append the "pres:" Presence URI scheme to the front MUST append the "pres:" Presence URI scheme to the front of the
of the address. address.
o The XMPP 'to' attribute (node@domain) MUST be mapped to the CPP o The XMPP 'to' attribute (user@host) MUST be mapped to the CPP
"target parameter" field (pres:node@domain). The XMPP-CPIM gateway "target parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST append the "pres:" Presence URI scheme to the front of the MUST append the "pres:" Presence URI scheme to the front of the
address. address.
o The CPP "duration parameter" MUST be set to zero. o The CPP "duration parameter" MUST be set to zero.
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
field. field.
If the target parameter (XMPP "to" address) does not refer to a valid If the target parameter (XMPP "to" address) does not refer to a valid
presentity, the XMPP-CPIM gateway MUST return an <item-not-found/> presentity, the XMPP-CPIM gateway MUST return an <item-not-found/>
skipping to change at page 33, line 44 skipping to change at page 31, line 28
XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
notifications to the XMPP entity. notifications to the XMPP entity.
5.6 Cancelling a Subscription 5.6 Cancelling a Subscription
If an XMPP entity wants to cancel a non-XMPP presentity's If an XMPP entity wants to cancel a non-XMPP presentity's
subscription to the entity's presence through an XMPP-CPIM gateway, subscription to the entity's presence through an XMPP-CPIM gateway,
it MUST send a presence stanza of type "unsubscribed" to the target it MUST send a presence stanza of type "unsubscribed" to the target
presentity. The syntax mapping is as follows: presentity. The syntax mapping is as follows:
o The CPP "watcher parameter" field (pres:node@domain) MUST be o The CPP "watcher parameter" field (pres:user@host) MUST be mapped
mapped to the XMPP 'from' attribute (node@domain). The XMPP-CPIM to the XMPP 'from' attribute (user@host). The XMPP-CPIM gateway
gateway MUST remove the "pres:" Presence URI scheme from the front MUST remove the "pres:" Presence URI scheme from the front of the
of the address. address.
o The CPP "target parameter" field (pres:node@domain) MUST be mapped o The CPP "target parameter" field (pres:user@host) MUST be mapped
to the XMPP 'to' attribute (node@domain). The XMPP-CPIM gateway to the XMPP 'to' attribute (user@host). The XMPP-CPIM gateway
MUST remove the "pres:" Presence URI scheme from the front of the MUST remove the "pres:" Presence URI scheme from the front of the
address. address.
o The CPP "duration parameter" MUST be set to zero. o The CPP "duration parameter" MUST be set to zero.
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
field. field.
Upon receiving the presence stanza of type "unsubscribed" from the Upon receiving the presence stanza of type "unsubscribed" from the
XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
notifications to the watcher presentity. notifications to the watcher presentity.
6. Mapping of Character Encodings 6. Internationalization Considerations
The following rules apply to the mapping of character encodings
(charsets):
1. A gateway SHOULD NOT map a "Message/CPIM" object whose charset is 6.1 Addresses
other than "us-ascii", "utf-8", or "utf-16".
2. A gateway SHOULD map a "Message/CPIM" object whose charset is Although XMPP enables full internationalization of XMPP addresses
"us-ascii" no matter whether the character encoding negotiated (see [XMPP-CORE]), there is no guarantee that non-XMPP addresses can
for the XMPP recipient's XML stream is UTF-8 or UTF-16. include characters other than [US-ASCII]. If an XMPP user attempts to
communicate with a non-XMPP user through an XMPP-CPIM gateway, the
XMPP user SHOULD NOT assume that the non-XMPP service supports fully
internationalized addresses.
3. A gateway SHOULD map a "Message/CPIM" object whose charset is 6.2 Character Encodings
"utf-8" if the character encoding negotiated for the XMPP
recipient's XML stream is UTF-8.
4. A gateway SHOULD map a "Message/CPIM" object whose charset is The following rules apply to the mapping of character encodings
"utf-16" if the character encoding negotiated for the XMPP (charsets):
recipient's XML stream is UTF-16.
5. A gateway SHOULD NOT map a "Message/CPIM" object whose charset is 1. A gateway SHOULD map a "Message/CPIM" object whose charset is
"utf-8" if the character encoding negotiated for the XMPP "US-ASCII" or "UTF-8".
recipient's XML stream is UTF-16.
6. A gateway SHOULD NOT map a "Message/CPIM" object whose charset is 2. A gateway SHOULD NOT map a "Message/CPIM" object whose charset is
"utf-16" if the character encoding negotiated for the XMPP other than "US-ASCII" or "UTF-8".
recipient's XML stream is UTF-8.
7. Security Considerations 7. Security Considerations
Detailed security considerations for instant messaging and presence Detailed security considerations for instant messaging and presence
protocols are given in RFC 2779 [1], specifically in Sections 5.1 protocols are given in [IMP-REQS], specifically in Sections 5.1
through 5.4. through 5.4.
This document specifies methods for exchanging instant messages and This document specifies methods for exchanging instant messages and
presence information through a gateway that implements CPIM [2] and presence information through a gateway that implements [CPIM] and
CPP [3]. Such a gateway MUST be compliant with the minimum security [CPP]. Such a gateway MUST be compliant with the minimum security
requirements of the instant messaging and presence protocols with requirements of the instant messaging and presence protocols with
which it interfaces. The introduction of gateways to the security which it interfaces. The introduction of gateways to the security
model of instant messaging and presence in RFC 2779 also introduces model of instant messaging and presence in RFC 2779 also introduces
some new risks. In particular, end-to-end security properties some new risks. In particular, end-to-end security properties
(especially confidentiality and integrity) between instant messaging (especially confidentiality and integrity) between instant messaging
and presence user agents that interface through an XMPP-CPIM gateway and presence user agents that interface through an XMPP-CPIM gateway
can be provided only if common formats are supported; these formats can be provided only if common formats are supported; these formats
are specified fully in End-to-End Object Encryption in XMPP [8]. are specified fully in [XMPP-E2E].
Normative References Normative References
[1] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / [CPIM] Peterson, J., "Common Profile for Instant Messaging
Presence Protocol Requirements", RFC 2779, February 2000. (CPIM)", draft-ietf-impp-im-04 (work in progress), August
2003.
[2] Crocker, D. and J. Peterson, "Common Profile for Instant [CPP] Peterson, J., "Common Profile for Presence (CPP)",
Messaging (CPIM)", draft-ietf-impp-im-02 (work in progress), draft-ietf-impp-pres-04 (work in progress), August 2003.
March 2003.
[3] Crocker, D. and J. Peterson, "Common Profile for Presence [IMP-MODEL]
(CPP)", draft-ietf-impp-pres-02 (work in progress), March 2003. Day, M., Rosenberg, J. and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000,
<http://www.ietf.org/rfc/rfc2778.txt>.
[4] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging [IMP-REQS]
Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
progress), January 2003. Presence Protocol Requirements", RFC 2779, February 2000.
[5] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. and [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
J. Peterson, "CPIM Presence Information Data Format", Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant
Messaging Message Format", draft-ietf-impp-cpim-msgfmt-08
(work in progress), January 2003.
[PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W.
and J. Peterson, "CPIM Presence Information Data Format",
draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.
[6] Saint-Andre, P. and J. Miller, "XMPP Core", [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
draft-ietf-xmpp-core-17 (work in progress), August 2003. Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", [US-ASCII]
draft-ietf-xmpp-im-16 (work in progress), August 2003. Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969.
[8] Saint-Andre, P., "End-to-End Object Encryption in XMPP", [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
draft-ietf-xmpp-e2e-04 (work in progress), June 2003. 10646", RFC 2279, January 1998.
[9] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and [XMPP-CORE]
Instant Messaging", RFC 2778, February 2000, <http:// Saint-Andre (ed.), P., "Extensible Messaging and Presence
www.ietf.org/rfc/rfc2778.txt>. Protocol (XMPP): Core", draft-ietf-xmpp-core-20 (work in
progress), November 2003.
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement [XMPP-E2E]
Levels", BCP 14, RFC 2119, March 1997. Saint-Andre (ed.), P., "End-to-End Object Encryption in
the Extensible Messaging and Presence Protocol (XMPP)",
draft-ietf-xmpp-e2e-06 (work in progress), November 2003.
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [XMPP-IM] Saint-Andre (ed.), P., "Extensible Messaging and Presence
Extensions (MIME) Part One: Format of Internet Message Bodies", Protocol (XMPP): Instant Messaging and Presence",
RFC 2045, November 1996. draft-ietf-xmpp-im-19 (work in progress), November 2003.
Informative References Informative References
[12] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [MIMETYPES]
Extensions (MIME) Part Two: Media Types", RFC 2046, November Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1996. Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
Authors' Addresses Author's Address
Peter Saint-Andre Peter Saint-Andre
Jabber Software Foundation Jabber Software Foundation
EMail: stpeter@jabber.org EMail: stpeter@jabber.org
Tony Bamonti
Jabber, Inc.
EMail: tbamonti@jabber.com
Appendix A. Revision History Appendix A. Revision History
Note to RFC Editor: please remove this entire appendix, and the Note to RFC Editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to publication. corresponding entries in the table of contents, prior to publication.
A.1 Changes from draft-ietf-xmpp-cpim-01 A.1 Changes from draft-ietf-xmpp-cpim-02
o Removed references to UTF-16.
o Changed MUST NOT to SHOULD NOT for mapping of courtesy copy data.
o Added information about internationalization of addresses.
o Completed formatting changes to meet RFC Editor requirements.
A.2 Changes from draft-ietf-xmpp-cpim-01
o Added subsection about handling presence notifications for o Added subsection about handling presence notifications for
multiple XMPP resources and multiple PIDF tuples. multiple XMPP resources and multiple PIDF tuples.
o Added subsection about PIDF documents that contain zero tuples. o Added subsection about PIDF documents that contain zero tuples.
o Further specified mapping between XMPP JIDs and CPIM instant o Further specified mapping between XMPP addresses and CPIM instant
inboxes and presentities. inboxes and presentities.
A.2 Changes from draft-ietf-xmpp-cpim-00 A.3 Changes from draft-ietf-xmpp-cpim-00
o Updated references. o Updated references.
o Made several small editorial changes. o Made several small editorial changes.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
 End of changes. 166 change blocks. 
491 lines changed or deleted 431 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/