Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
Extracted elements (24)
XMPP and CPIM are distinctly foreign technologies: XMPP is an XML streaming protocol not based on MIME, whereas CPIM uses MIME content-types ('Message/CPIM' and 'application/pidf+xml') as common formats. The mapping approach translates XMPP elements/attributes to CPIM headers and MIME formats to achieve interworking via a dedicated gateway.
XMPP does not include syntax for 'cc' (courtesy copy), 'DateTime', or 'Subject' headers found in 'Message/CPIM' objects. Rather than inventing XMPP extensions, the gateway is instructed to SHOULD NOT pass these headers through, reflecting the deliberate scoping of this memo to core protocol elements only.
PIDF can carry multiple tuples (representing multiple resources), but XMPP can only send presence for one resource at a time per stanza. A gateway SHOULD split a multi-tuple PIDF document into multiple XMPP presence stanzas, and SHOULD aggregate multiple XMPP resources into one PIDF document with multiple tuples.
XMPP subscriptions are active until explicitly terminated, but non-XMPP services may implement subscriptions of limited duration requiring periodic refresh. An XMPP-to-CPIM gateway may need to send such refreshes on behalf of the XMPP entity to prevent subscription expiry.
An XMPP-CPIM gateway MUST NOT generate a PIDF document with zero <tuple/> children when receiving a presence stanza from an XMPP entity; all PIDF documents communicated to a non-XMPP service MUST contain at least one <tuple/> element.
An XMPP-CPIM gateway MUST NOT map to an XMPP presence stanza a 'Message/CPIM' object whose encapsulated MIME Content-type is other than 'application/pidf+xml' (except for multi-part MIME objects as specified in XMPP-E2E).
An XMPP-CPIM gateway MUST NOT pass CPIM 'NS' header extensions through to the XMPP recipient; no mapping for such headers is defined.
An XMPP-CPIM gateway SHOULD ignore XMPP message extended content (non-core namespaces) and not pass it through to the recipient, with the exception of 'urn:ietf:params:xml:ns:xmpp-e2e' content defined in XMPP-E2E.
For presence mapping, the 'Content-type' of the encapsulated MIME object MUST be set to 'application/pidf+xml' and the charset MUST be set to 'utf-8'.
If a subscription request is denied, the XMPP-CPIM gateway MUST return a presence stanza of type 'unsubscribed' and MUST NOT invoke the notify operation. Specific stanza errors MUST be returned for invalid target (<item-not-found/>), forbidden access (<forbidden/>), and optionally for pre-existing subscriptions (<conflict/>).
If an XMPP <priority/> element has a negative value, the gateway MUST NOT map it to a PIDF priority attribute. When mapping, XMPP priority 0 SHOULD map to PIDF priority='0' and XMPP priority 127 SHOULD map to PIDF priority='1', with intermediate values mapped uniquely.
If the encapsulated MIME Content-Type is not 'text/plain', the gateway MUST NOT map it to the XMPP <body/> element; if the charset is neither 'US-ASCII' nor 'UTF-8', the gateway SHOULD NOT map the 'Message/CPIM' object at all.
The XMPP 'id' attribute SHOULD NOT be mapped to the MIME Content-ID header because the XMPP 'id' is not a globally-unique identifier; however, if the 'id' is known to be globally unique, it SHOULD be so mapped.
To map the XMPP 'from' attribute of a message stanza to the CPIM 'From' header, the gateway MUST remove the resource identifier and MUST append the 'im:' URI scheme; it MAY include a CPIM 'Formal-name' for the sender.
When a subscription request is approved, the XMPP-CPIM gateway MUST return a 'subscribed' presence stanza to the XMPP entity and notify it of the target's current available presence; thereafter the gateway MUST notify on every presence change until cancellation.
When mapping an XMPP message stanza to a 'Message/CPIM' object, the Content-type MUST be set to 'text/plain' and the charset MUST be set to 'utf-8', because XMPP uses UTF-8 exclusively and the MIME default of 'text/plain; charset=us-ascii' would be incorrect.
When mapping CPIM 'From' to an XMPP message 'from' attribute, the gateway MUST remove the 'im:' URI scheme and MUST remove the CPIM 'Formal-name' if provided.
When unsubscribing, the gateway MUST set the CPP 'duration parameter' to zero, and upon receiving the 'unsubscribe' stanza the gateway MUST NOT send further presence notifications to the XMPP entity.
Address mapping between XMPP JIDs and im:/pres: URIs must handle character set differences: '&', ''', and '/' are allowed in im:/pres: URIs but not XMPP addresses, while many UTF-8 characters are allowed in XMPP but not in im:/pres: URIs.
An XMPP-CPIM gateway translates between XMPP services and non-XMPP services using CPIM specifications as common formats. The gateway is a dedicated translator, not an intermediate hop, and the mapping applies only to unencrypted, unsigned instant messages and presence information.
The XMPP <show/> element values ('away', 'chat', 'dnd', 'xa') map to extended <status/> content in the PIDF 'urn:ietf:params:xml:ns:pidf:im' namespace; the XMPP <status/> element maps to the PIDF <note/> child of the <tuple/> element.
The XMPP-to-CPIM address mapping algorithm strips the resource identifier, optionally applies Nodeprep/STRINGPREP canonicalization, translates special characters (#26;→&, #27;→', #2f;→/), percent-encodes remaining non-safe bytes, and prepends 'im:' (for messages) or 'pres:' (for presence) as the URI scheme.
XMPP presence type maps to PIDF basic presence status: absence of a 'type' attribute maps to PIDF OPEN, and 'type=unavailable' maps to PIDF CLOSED. All other XMPP presence types (subscribe, unsubscribe, etc.) manage subscriptions and are handled separately in Section 6.
An XMPP-CPIM gateway MUST comply with the minimum security requirements of the instant messaging and presence protocols it interfaces with. End-to-end security properties (confidentiality and integrity) between user agents through a gateway can only be provided if common formats are supported, as specified in XMPP-E2E (RFC 3923).