Common Presence and Instant Messaging (CPIM): Message Format
Extracted elements (29)
Pure RFC 2822/MIME was not used because of its irregular lexical structure (multiple encodings making digest computation unreliable), weak internationalization (7-bit ASCII only), mutability by gateways that obliterates signatures, lack of clear metadata/content separation, and limited extensibility via unstandardizable X-headers.
The message format is intentionally agnostic about specific security mechanisms, providing a canonical format as a basis for signature calculation while leaving the choice of security protocols (S/MIME, OpenPGP, etc.) to application-level specifications such as the CPIM IM and CPIM presence specs.
The namespace extensibility framework is modeled on XML namespaces to allow different implementers to create extension headers without name collision risk. Namespace prefixes are strictly local to a message; only the namespace URI has global significance, so different prefix strings can denote identical namespaces across messages.
Very strict adherence to the Message/CPIM message format — including whitespace usage — may be needed to achieve interoperability, as the format is designed for end-to-end security where any deviation can break signature verification.
A namespace prefix declaration (NS header) MUST precede any use of that prefix within a message. Any URI used as a namespace identifier MUST be a full absolute-URI per RFC 2396; relative URIs and fragment identifiers MUST NOT be used.
Header names MUST match exactly — 'From:' and 'from:' are different headers. All specified text values MUST use exactly the indicated upper- and lower-case letters.
Headers MUST NOT contain any control characters (0–31). If a header value needs to represent control characters, the escape mechanism described in section 2.3 MUST be used.
Message headers MUST NOT be modified, reformatted or reordered in transit, but in some circumstances they MAY be examined by a CPIM message transfer protocol.
Message processors MUST preserve all octets of all headers (both name and value) exactly, and MUST NOT change the order of message headers.
Processors SHOULD NOT impose any line-length limitations on message headers.
The character sequence CR,LF (13,10) MUST be used to terminate each header line, and the entire header MUST be contained on a single line with no whitespace at the beginning or end.
The MIME content portion of a Message/CPIM object MUST include at least a Content-Type header. The content may be any MIME type.
UTF-8 character encoding MUST be used throughout message headers.
Within a network of message transfer agents, an intermediate gateway MUST NOT change the Message/CPIM content in any way — headers cannot be changed or reordered, transfer encoding cannot be changed. A transfer agent wishing to modify content must create a new Message/CPIM message with the original as its content.
A Message/CPIM object is a two-part entity: the first part contains message metadata headers and the second part is the MIME-encapsulated message content. The two parts are separated from the enclosing MIME headers and from each other by blank lines.
Headers are associated with namespaces identified by globally-unique URIs, using a prefix declaration mechanism modeled on XML namespaces. An NS header without a prefix name sets the default namespace; namespace prefixes are strictly local to the message instance.
The 'cc' header (namespace: urn:ietf:params:cpim-headers:) specifies a non-primary courtesy-copy recipient. Multiple 'cc' headers indicate multiple courtesy-copy recipients. The header name 'cc' is case-sensitive.
The 'DateTime' header (namespace: urn:ietf:params:cpim-headers:) carries the date and time the sender sent the message using ISO 8601 format as profiled in RFC 3339. One purpose is replay-attack protection by allowing the recipient to know the intended send time.
The 'From' header (namespace: urn:ietf:params:cpim-headers:) indicates the sender with syntax: "From" ": " [Formal-name] "<" URI ">". The header name is case-sensitive.
The 'NS' header (namespace: urn:ietf:params:cpim-headers:) declares a local namespace prefix associated with a URI for use in subsequent header names within the message. Its syntax is: "NS" ": " [Name-prefix] "<" URI ">".
The 'Require' header indicates a header or feature that must be understood by the receiver for correct message processing. Multiple required header names may be listed in a single 'Require' header separated by commas. The Require header may reference non-header semantics as well.
The 'Subject' header (namespace: urn:ietf:params:cpim-headers:) carries the message topic and supports per-header language tagging via a ';lang=' parameter per RFC 3066. Multiple Subject headers with different language parameters are permitted.
The 'To' header (namespace: urn:ietf:params:cpim-headers:) specifies an intended recipient with syntax: "To" ": " [Formal-name] "<" URI ">". Multiple recipients are indicated by multiple 'To' headers.
Registers the IANA URN sub-namespace 'urn:ietf:params:cpim-headers:' per RFC 3553. Index values are CPIM message header names; URNs are formed by percent-encoding non-URN characters in the header name and prepending the namespace prefix string.
Registers the MIME media type Message/CPIM (message/cpim) with IANA per RFC 2048. The type has no required or optional parameters, is intended for 8-bit clean environments, and uses 'urn:ietf:params:cpim-headers:' as its default namespace URI.
Because Message/CPIM messages use UTF-8 (binary), they must be tunneled intact across non-8-bit-clean transports — changing data encoding is not an option. MIME base64 content-transfer-encoding may be applied to the whole Message/CPIM object to meet this requirement without data loss.
Message/CPIM messages must be considered immutable once created, as the format is designed for use with MIME security multiparts for end-to-end signatures and encryption. Any modification after signing invalidates the signature.
Header syntax (ABNF): Header = Header-name ":" *(";") Parameter) SP Header-value CRLF. Header-name may include an optional namespace prefix separated by ".". Header values are sequences of HEADERCHAR (any UCS character except CTLs or escape sequences) encoded in UTF-8.
The character escape mechanism uses the form \uxxxx where xxxx is exactly four hexadecimal digits representing the UCS code-point. Special sequences include \\, \", \', \b, \t, \n, and \r. This mechanism MUST be used for control characters (U+0000–U+001F or U+007F) appearing anywhere in a header.