Common Profile for Instant Messaging (CPIM)
Extracted elements (21)
Loop detection via MaxForwards is necessary because aliasing and group list expansions can legitimately cause a message to pass through a relay more than once, making loop detection non-trivial by inspection alone.
Service behavior is described abstractly (operations and attributes) rather than prescribing wire encoding, allowing each IM protocol to map CPIM semantics onto its own native format (textual key/value pairs, compact binary, nested containers, etc.) while remaining gateway-compatible.
Source-route mapping (encoding the original address in the local-part and the gateway in the domain part, e.g., 'im:pepp=example.com/fred@relay-domain') is the easiest gateway technique but has a history of operational problems and poor human usability; the underlying software should hide it from end-users where possible.
End-to-end security properties (confidentiality, integrity) across CPIM gateways are only achievable if all participating IM protocols support the common MSGFMT format; gateways cannot themselves provide end-to-end security for content they relay opaquely.
Applications that send message operations to a CPIM gateway MUST implement the common message format defined in MSGFMT (RFC 3862) in order to maintain end-to-end security properties. Applications MAY support other content formats.
Certificates used for S/MIME IM operations SHOULD contain a subjectAltName field with the IM URI of the subject, to provide reference integrity when IM URIs convey sender/recipient identity.
Compliant IM service implementations SHOULD follow the URI dereferencing guidelines in RFC 3861 to determine the next hop for forwarding an instant message.
CPIM gateways MUST be capable of relaying the content of a message operation between supported instant messaging protocols without needing to modify or inspect the content.
CPIM gateways MUST be compliant with the minimum security requirements of each instant messaging protocol with which they interface.
Implementations MAY use AES as an encryption algorithm (it is preferred as best-suited to many platforms) but are REQUIRED to support only the baseline algorithms mandated by S/MIME and CMS.
When end-to-end security is required, the message operation MUST use MSGFMT and MUST secure the MSGFMT MIME body with S/MIME using CMS EnvelopeData (encryption) and/or CMS SignedData (signatures).
When mapping IM addresses, address mappings that place special information into the im: address local-part MUST use the meta-syntax defined in RFC 2846.
An INSTANT INBOX is identified using an instant messaging URI with the 'im:' URI scheme, e.g., 'im:[email protected]'. The IM URI is the canonical address form used as source and destination in message operations.
MaxForwards is a hop counter used to detect routing loops through CPIM gateways. Each gateway decrements the value when relaying; if a gateway receives a message with MaxForwards=0 it discards the message and invokes a failure response. An initial value over one hundred is recommended.
The message operation carries four attributes: 'source' and 'destination' (INSTANT INBOX identifiers), 'MaxForwards' (hop counter set by originator to prevent loops), and 'TransID' (unique identifier to correlate message and response operations). Gateways SHOULD handle TransIDs up to 40 bytes.
The response operation carries two attributes: 'TransID' (matching the originating message operation) and 'status', which indicates success, failure, or indeterminant delivery outcome.
IANA has assigned the 'im' URI scheme for designating INSTANT INBOXes on the Internet. The scheme is registered under the IETF tree with IETF maintaining change control.
The introduction of CPIM gateways creates new risks: end-to-end confidentiality and integrity between IM user agents that communicate through a CPIM gateway can only be guaranteed if both sides support a common IM message format (MSGFMT) secured with S/MIME.
Users and service providers are encouraged to employ widely-accepted trust anchors for S/MIME certificates rather than trust anchors specific to any particular IM service, to facilitate interoperability of secure messaging through CPIM gateways.
Upon receiving a message operation, the service checks: (1) syntactic validity of source/destination — failure if invalid; (2) resolvability of destination — failure if unresolvable and not final recipient; (3) access control — failure if denied. On success: 'success' if delivered, 'failure' if delivery fails, 'indeterminant' if delegated with no future authoritative indication, or deferred response if delegation will yield a future indication.
The IM URI syntax follows the mailto: URI pattern. ABNF: IM-URI = 'im:' [ to ] [ headers ]; to = mailbox; headers = '?' header *('&' header); header = hname '=' hvalue. 'mailbox' is as defined in RFC 2822; 'uric' denotes any URL-valid character per RFC 2396.