RFC 3862

Common Presence and Instant Messaging (CPIM): Message Format ✨

okay so this one is RFC 3862 🎀 It's a Standards Track document from August 2004, written by G. Klyne of Nine by Nine and D. Atkins of IHTFP Consulting. It was published in the Network Working Group, and it's the spec that defines the MIME content type Message/CPIM 💅 Nothing in its header says it obsoletes or updates another RFC.

Status of This Memo

bestie, this part is the official "what kind of doc is this" bit 🧚 It's an Internet standards track protocol spec for the Internet community, and it asks for discussion and suggestions for improvements. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

Copyright Notice

Copyright (C) The Internet Society (2004).

Abstract

this memo is all about one thing: defining the MIME content type 'Message/CPIM' 🦋 It's a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification ✨

Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . .  3
    1.2.  Background . . . . . . . . . . . . . . . . . . . . . . .  3
    1.3.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . .  4
    1.4.  Terminology and Conventions  . . . . . . . . . . . . . .  5
2.  Overall Message Structure  . . . . . . . . . . . . . . . . . .  5
    2.1.  Message/CPIM MIME Headers  . . . . . . . . . . . . . . .  6
    2.2.  Message Headers  . . . . . . . . . . . . . . . . . . . .  6
    2.3.  Character Escape Mechanism . . . . . . . . . . . . . . .  8
          2.3.1.  Escape Mechanism Usage . . . . . . . . . . . . .  8
    2.4.  Message Content  . . . . . . . . . . . . . . . . . . . .  9
3.  Message Header Syntax  . . . . . . . . . . . . . . . . . . . . 10
    3.1.  Header Names . . . . . . . . . . . . . . . . . . . . . . 10
    3.2.  Header Value . . . . . . . . . . . . . . . . . . . . . . 10
    3.3.  Language tagging . . . . . . . . . . . . . . . . . . . . 10
    3.4.  Namespaces for Header Name Extensibility . . . . . . . . 11
    3.5.  Mandatory-to-Recognize Features  . . . . . . . . . . . . 13
    3.6.  Collected Message Header Syntax  . . . . . . . . . . . . 14
4.  Header Definitions . . . . . . . . . . . . . . . . . . . . . . 16
    4.1.  The 'From' Header  . . . . . . . . . . . . . . . . . . . 16
    4.2.  The 'To' Header  . . . . . . . . . . . . . . . . . . . . 17
    4.3.  The 'cc' Header  . . . . . . . . . . . . . . . . . . . . 18
    4.4.  The 'DateTime' Header  . . . . . . . . . . . . . . . . . 18
    4.5.  The 'Subject' Header . . . . . . . . . . . . . . . . . . 19
    4.6.  The 'NS' Header  . . . . . . . . . . . . . . . . . . . . 20
    4.7.  The 'Require' Header . . . . . . . . . . . . . . . . . . 20
5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
    5.1.  An Example Message/CPIM Message  . . . . . . . . . . . . 21
    5.2.  An Example Esing MIME multipart/signed . . . . . . . . . 22
6.  Application Design Considerations  . . . . . . . . . . . . . . 22
7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
    7.1.  Registration for Message/CPIM Content Type . . . . . . . 24
    7.2.  Registration for urn:ietf:params:cpim-headers  . . . . . 25
8.  Internationalization Considerations  . . . . . . . . . . . . . 26
9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
    11.1.  Normative References. . . . . . . . . . . . . . . . . . 26
    11.2.  Informative References. . . . . . . . . . . . . . . . . 27
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30

1. Introduction ✨

okay so the core idea 💖 This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. It's a common message format for CPIM-compliant messaging protocols [26].

the format is pretty general, so other applications with similar needs can reuse it too 🌈 If an application spec adopts this as its base format, it should address the questions raised in section 6 of this document.

1.1. Motivation

the CPIM [26] specification defines a bunch of operations and criteria for interworking between different instant messaging protocols 🍓 The goal is letting different protocols talk to each other through gateways, so you get cross-protocol messaging that meets the requirements of RFC 2779 [20].

to meet RFC 2779's security requirements, you need a common message format so end-to-end signatures and encryption can be applied 🔥 This document describes a common canonical message format that must be used by any CPIM-compliant message transfer protocol, and signatures are calculated over it for end-to-end security.

the design is meant to let security be applied while staying agnostic about which security mechanisms fit a given application 🫶 For CPIM instant messaging and presence, the specific security protocols are specified by the CPIM instant messaging [26] and CPIM presence [27] specifications.

also, the message format here is not a MIME data format on its own 🙈 It can be contained within a MIME object, and it can contain MIME objects too. See section 2 for more details.

1.2. Background

RFC 2779 says an instant message can carry a MIME payload [1][2] ✨ So some level of MIME support will be a common element of any CPIM-compliant protocol. It makes sense for a common message format to use a RFC2822/MIME-like syntax [9], since protocol implementations must already have code to parse it 💅

BUT pure RFC2822/MIME can be problematic, and here's why 😭

• Irregular lexical structure -- RFC2822/MIME allows a number of optional encodings and multiple ways to encode a particular value. For example, RFC2822/MIME comments may be encoded in multiple ways. For security purposes, a single encoding method must be defined as a basis for computing message digest values. Protocols that transmit data in a different format would otherwise lose information needed to verify a signature.
• Weak internationalization -- RFC2822/MIME requires header values to use 7-bit ASCII, which is problematic for encoding international character sets. Mechanisms for language tagging in RFC2822/MIME headers [16] are awkward to use and have limited applicability.
• Mutability -- addition, modification or removal of header information. Because it is not explicitly forbidden, many applications that process MIME content (e.g., MIME gateways) rebuild or restructure messages in transit. This obliterates most attempts at achieving security (e.g., signatures), leaving receiving applications unable to verify the data received.
• Message and payload separation -- there is not a clear syntactic distinction between message metadata and message content.
• Limited extensibility. (X-headers are problematic because they may not be standardized; this leads to situations where a header starts out as experimental but then finds widespread application, resulting in a common usage that cannot be standardized.)
• No support for structured information (text string values only).
• Some processors impose line length limitations.

the format defined by this memo fixes some of these problems 🎀 It has a simplified syntax that is generally compatible with the format accepted by RFC2822/MIME parsers, and a stricter syntax on top. It also defines mechanisms to support some desired features that the RFC2822/MIME format specifications don't cover.

1.3. Goals

this spec is aiming for these goals 🦋

• a securable end-to-end format for a message (a canonical message format to serve as a basis for signature calculation, rather than specified security mechanisms).
• independence of any specific application
• capability of conveying a range of different address types
• assumption of an 8-bit clean message-transfer protocol
• evolvable: extensible by multiple parties
• a clear separation of message metadata from message content
• a simple, regular, easily parsed syntax
• a compact, low-overhead format for simple messages

1.4. Terminology and Conventions

so the key words section is the official translation key 🧚 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [4].

NOTE: Comments like this provide additional nonessential information about the rationale behind this document. Such information is not needed for building a conformant implementation, but may help those who wish to understand the design in greater depth. 💜

2. Overall Message Structure ✨

a CPIM message wraps arbitrary MIME message content together with the message- and content-related metadata 🌸 This can optionally be signed or encrypted using MIME security multiparts, combined with an appropriate security scheme.

a Message/CPIM object is a two-part entity 💖 The first part holds the message metadata, and the second part is the message content. The two parts are separated from the enclosing MIME header fields, and from each other, by blank lines. The metadata header information follows way stricter syntax rules than the MIME content headers that can be carried inside the message 😤

a complete message looks something like this:

m: Content-type: Message/CPIM
s:
h: (message-metadata-headers)
s:
e: (encapsulated MIME message-body)

the end of the message body is defined by the framing mechanism of whatever protocol is being used 🫶 The tags 'm:', 's:', 'h:', 'e:', and 'x:' are not part of the message format. They're just used here to point out the different parts of the message, like this:

m:  MIME headers for the overall message
s:  a blank separator line
h:  message headers
e:  encapsulated MIME object containing the message content
x:  MIME security multipart message wrapper

2.1. Message/CPIM MIME Headers

the message MIME headers are what identify the message as a CPIM-formatted message 🍓

the only required MIME header is:

Content-type: Message/CPIM

Other MIME headers may be used as appropriate for the message transfer environment. ✨

2.2. Message Headers ✨

okay so message headers are the info that travels end-to-end from sender to receiver 💌 and they MUST NOT be modified, reformatted or reordered in transit 🙅‍♀️. sometimes though, a CPIM message transfer protocol MAY peek at them 👀

these headers give major RFC 2822 email header energy [9], just with a more restricted syntax 💅

the basic header syntax is literally just:

Key: Value

where Key is a header name and Value is the header value that goes with it 🎀

here are the vibe checks you need:

• the entire header MUST be contained on a single line 📏 the line terminator doesn't count as part of the header value
• only one header per line 🙅‍♀️ multiple headers MUST NOT be crammed onto a single line
• processors SHOULD NOT impose any line-length limitations 🌈
• there MUST NOT be any whitespace at the beginning or end of a line 🧼
• UTF-8 character encoding [13] MUST be used throughout 🫶
• the character sequence CR,LF (13,10) MUST be used to terminate each line 💫
• the header name contains only US-ASCII characters (see section 3.1 and section 3.6 for the specific syntax) 🔤
• the header MUST NOT contain any control characters (0-31) 🚫 if a header value needs to represent control characters, the escape mechanism described below MUST be used 🦋
• there MUST be a single space character (32) following the header name and colon 🌸
• multiple headers using the same key (header name) are allowed ✨ (specific header semantics may dictate only one occurrence of any particular header)
• header names MUST match exactly, so "From:" and "from:" are totally different headers 💀
• if a header name is not recognized or not understood, the header should be ignored 🙈 but see also the Require: header (section 4.7)
• interpretation (e.g., equivalence) of header values depends on the particular header definition 🧠 message processors MUST preserve all octets of all headers (both name and value) exactly 💜
• message processors MUST NOT change the order of message headers 👑

examples, because you know I love a good example 🧚:

To: Pooh Bear <im:pooh@100akerwood.com>
From: <im:piglet@100akerwood.com>
DateTime: 2001-02-02T10:48:54-05:00

2.3. Character Escape Mechanism 🦄

this mechanism MUST be used to code control characters in a header, meaning Unicode code points in the range U+0000 to U+001f or U+007f. (instead of inventing something completely new, the escape mechanism was borrowed from the one the Java programming language uses 💅)

ngl this next bit matters a LOT the escape mechanism is applied to a UCS-2 character, NOT to the octets of its UTF-8 coding 😭 mapping to and from UTF-8 coding happens without caring about escape sequences or character coding. (the header syntax is designed so that octets for control characters other than CR and LF never show up in the output 🌈)

an arbitrary UCS-2 character is escaped using this form:

\uxxxx

where:

\     is U+005c (backslash)
u     is U+0075 (lower case letter U)
xxxx  is a sequence of exactly four hexadecimal digits
      (0-9, a-f or A-F) or
      (U+0030-U+0039, U+0041-U+0046, or U+0061-0066)

the hexadecimal number xxxx is the UCS code-point value of the escaped character 🔥

there are also special sequences that start with \:

\\    for \ (backslash, U+005c)
\"    for " (double quote, U+0022)
\'    for ' (single quote, U+0027)
\b    for backspace (U+0008)
\t    for tab (U+0009)
\n    for linefeed (U+000a)
\r    for carriage return (U+000d)

2.3.1. Escape Mechanism Usage 🎀

when generating messages that conform to this specification:

• the special sequences listed above MUST be used to encode any occurrence of these characters anywhere in a header: backslash (U+005c), backspace (U+0008), tab (U+0009), linefeed (U+000a) or carriage return (U+000d) 🙌
• the special sequence \" MUST be used for any occurrence of a double quote (U+0022) that appears within a string delimited by double quotes 💖
• the special sequence \' MUST be used for any occurrence of a single quote (U+0027) that appears within a string delimited by single quotes 💖
• single- or double-quote characters that delimit a string value MUST NOT be escaped 🙅‍♀️
• the general escape sequence \uxxxx MUST be used for any other control character (U+0000 to U+0007, U+000b to U+000c, U+000e to U+001f or u+007f) that appears anywhere in a header 🧯
• all other characters MUST NOT be represented using an escape sequence 🚫

when processing a message based on this specification, the escape sequence usage described above MUST be recognized 👀

any other occurrence of an escape sequence described above SHOULD be recognized and treated as the corresponding Unicode character 🧠

any backslash (\) character SHOULD be interpreted as introducing an escape sequence. any unrecognized escape sequence SHOULD be treated as an instance of the character following the backslash character. an isolated backslash that is the last character of a header SHOULD be ignored 🙈

2.4. Message Content 🍓

the final section of a Message/CPIM is the MIME-encapsulated message content, which follows standard MIME formatting rules [1][2] 💌

the MIME content headers MUST include at least a Content-Type header. the content can be any MIME type 🌸

example time 🧚‍♀️:

e: Content-Type: text/plain; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: This is my encapsulated text message content

3. Message Header Syntax 💅

a header has two parts, a name and a value, separated by a colon character (:) and a single space (32). it ends with the sequence CR,LF (13,10) 🫶

headers use UTF-8 character encoding throughout, per RFC 3629 [13] 🌈

NOTE: in the descriptions that follow, header field names and other specified text values MUST be used exactly as given, using exactly the indicated upper- and lower- case letters. in this respect, the ABNF usage differs from RFC 2234 [6]. 🚨

3.1. Header Names 🔤

the header name is a sequence of US-ASCII characters, excluding control, SPACE or separator characters. the character . is reserved for use as a namespace prefix separator in a header name 🧚

separator characters are:

   SEPARATORS   = "(" / ")" / "<" / ">" / "@"
                / "," / ";" / ":" / "\" / DQUOTE
                / "/" / "[" / "]" / "?" / "="
                / "{" / "}" / SP

NOTE: the allowed character range was picked by looking at HTTP and RFC 2822 header name formats and going with the more restricted one 🧐 the goal is for CPIM headers to follow a syntax that works with the allowed syntax for both RFC 2822 [9] and HTTP [18] (including HTTP-derived protocols such as SIP [21]) 💖

3.2. Header Value 🎀

a header value has a structure defined by its corresponding header specification. implementations that use a particular header must adhere to the format and usage rules defined there when creating or processing a message containing that header 📋

the other general constraints on header formats MUST also be followed (one line, UTF-8 character encoding, no control characters, etc.) ✨

3.3. Language tagging 🌍

full internationalization of a protocol requires that a language can be indicated for any human-readable text [15][7] 🌏

a message header may indicate a language for its value by adding ;lang=tag after the header name and colon, where tag is a language identifying token per RFC 3066 [10] 💬

example:

Subject:;lang=fr Objet de message

if the language parameter isn't applied to a header, any human-readable text is assumed to use the language identified as 'i-default' [7] 🫧

3.4. Namespaces for Header Name Extensibility ✨

Okay bestie, heads up: this section is a framework for header extensibility, and using it is optional 🦋 If an application doesn't allow any header extensions, these structures may never get used.

An application that uses this message format is expected to define the set of headers it requires and allows. This section gives you a header extensibility framework that works with any application 💅

The framework is based on the one XML uses, which is XML namespaces [23]. Every header belongs to a "namespace", and each namespace is tied to a globally unique URI 🌸

Inside one message, a header name is linked to a namespace by whether it has a namespace prefix. The prefix is the leading part of the header name, followed by a period ("."). For example:

prefix.header-name: header-value

Here, prefix is the header name prefix, header-name is the header name inside the namespace that prefix points to, and header-value is the value of this header.

header-name: header-value

In this case there's no prefix, so the given header-name goes into a default namespace 🎀

The Message/CPIM media type registration sets a default namespace for any headers that aren't tied to a namespace more explicitly. Most of the time, that default namespace is all you need ✨

A namespace is identified by a URI. Here the URI is just a globally unique identifier, and there's no requirement that it be used for anything else. Any legal globally unique URI MAY be used to identify a namespace. (By "globally unique," we mean the URI was built using some set of rules, so you can reasonably expect nobody else to use it for something different.) A URI used as an identifier MUST be a full absolute-URI, per RFC 2396 [8]. (Relative URIs and URI-references containing fragment identifiers MUST NOT be used for this purpose.) 🔥

Within a specific message, an NS header declares a namespace prefix and links it to a URI that identifies a namespace. After that declaration, and within that message, the combination of namespace prefix and header name gives you a globally unique identifier for the header. That identifier is made of the namespace URI and the header name 💜

For example:

NS: MyFeatures <mid:MessageFeatures@id.foo.com>
MyFeatures.WackyMessageOption: Use-silly-font

This sets up a namespace prefix MyFeatures that's linked to the namespace identifier mid:MessageFeatures@id.foo.com. From then on, the prefix tells you that the WackyMessageOption header name belongs to that identified namespace 🌈

A namespace prefix declaration MUST precede any use of that prefix. ⭐

Except for any application-specific predefined namespace prefixes (see section 6), a namespace prefix only means something inside the message where it shows up. The actual prefix has no global meaning. So these headers:

xxx.name: value
yyy.name: value

in two different messages can do exactly the same thing, as long as the prefixes xxx and yyy both point to the same namespace URI. That means the following two have exactly the same meaning:

NS: acme <http://id.acme.widgets/wily-headers/>
acme.runner-trap: set

and

NS: widget <http://id.acme.widgets/wily-headers/>
widget.runner-trap: set

An NS header without a prefix name sets a default namespace for the headers that follow. That's a namespace tied to header names that don't have a prefix. For example:

NS: <http://id.acme.widgets/wily-headers/>
runner-trap: set

has the same meaning as the previous examples 🧚

This framework lets different implementers make their own extension headers without worrying about header names clashing, since each one defines headers inside its own namespace 💖

3.5. Mandatory-to-Recognize Features

Sometimes the sender of a message needs to insist that the recipient understands some functionality. With the mandatory-to-recognize indicator, the sender tells the recipient that it MUST understand the named header or feature in order to properly understand the message. 🫶

A header or feature gets marked as mandatory-to-recognize with a Require: header. For example:

Require: MyFeatures.VitalMessageOption
MyFeatures.VitalMessageOption: Confirmation-requested

You can list multiple required header names in a single Require header, separated by commas 💅

NOTE: Using Require: headers indiscriminately could hurt interoperability. So if you're an implementer who defines required headers, it's suggested that you also publish the header specifications, so other implementations can interoperate successfully 😭

The Require: header MAY also be used to say that the recipient has to implement some non-header semantics, even when they don't show up as a header. For example:

Require: Locale.MustRenderKanji

might be used to say that the message content includes characters from the Kanji repertoire, which must be rendered for the message to be properly understood 🎌 In this case, the header name is just a token (using header name syntax and namespace association) that points to some behaviour you want 🌸

3.6. Collected Message Header Syntax

Here's the message header syntax, written in ABNF, per RFC 2234 [6]. Most of this syntax can be read as defining UCS character sequences or UTF-8 octet sequences. The alternate productions at the end let you read it either way 🦋

NOTE: Specified text values MUST be used as given, using exactly the upper- and lower-case letters shown. On this point, the ABNF used here is different from RFC 2234 [6] 👑

Collected syntax:

Header       = Header-name ":" *( ";" Parameter ) SP
               Header-value
               CRLF

Header-name  = [ Name-prefix "." ] Name
Name-prefix  = Name

Parameter    = Lang-param / Ext-param
Lang-param   = "lang=" Language-tag
Ext-param    = Param-name "=" Param-value
Param-name   = Name
Param-value  = Token / Number / String

Header-value = *HEADERCHAR

Name         = 1*NAMECHAR
Token        = 1*TOKENCHAR
Number       = 1*DIGIT
String       = DQUOTE *( Str-char / Escape ) DQUOTE
Str-char     = %x20-21 / %x23-5B / %x5D-7E / UCS-high
Escape       = "\" ( "u" 4(HEXDIG)    ; UCS codepoint
                   / "b"              ; Backspace
                   / "t"              ; Tab
                   / "n"              ; Linefeed
                   / "r"              ; Return
                   / DQUOTE           ; Double quote
                   / "'"              ; Single quote
                   / "\" )            ; Backslash

Formal-name  = 1*( Token SP ) / String
URI          = <defined as absolute-URI by RFC 2396>
Language-tag = <defined by RFC 3066>

             ; Any UCS character except CTLs, or escape
HEADERCHAR   = UCS-no-CTL / Escape

             ; Any US-ASCII char except ".", CTLs or SEPARATORS:
NAMECHAR     = %x21 / %x23-27 / %x2a-2b / %x2d
             / %x5e-60 / %x7c / %x7e
             / ALPHA / DIGIT

             ; Any UCS char except CTLs or SEPARATORS:
TOKENCHAR    = NAMECHAR / "." / UCS-high

SEPARATORS   = "(" / ")" / "<" / ">" / "@"    ; 28/29/3c/3e/40
             / "," / ";" / ":" / "\" / DQUOTE ; 2c/3b/3a/5c/22
             / "/" / "[" / "]" / "?" / "="    ; 2f/5b/5d/3f/3d
             / "{" / "}" / SP                 ; 7b/7d/20
CTL          = <Defined by RFC 2234 -- %x0-%x1f, %x7f>
CRLF         = <Defined by RFC 2234 -- CR, LF>
SP           = <defined by RFC 2234 -- %x20>
DIGIT        = <defined by RFC 2234 -- '0'-'9'>
HEXDIG       = <defined by RFC 2234 -- '0'-'9', 'A'-'F', 'a'-'f'>
ALPHA        = <defined by RFC 2234 -- 'A'-'Z', 'a'-'z'>
DQUOTE       = <defined by RFC 2234 -- %x22>

To read the syntax in a general UCS character environment, use these productions:

UCS-no-CTL   = %x20-7e / UCS-high
UCS-high     = %x80-7fffffff

To read the syntax as defining UTF-8 coded octet sequences, use these productions:

UCS-no-CTL   = UTF8-no-CTL
UCS-high     = UTF8-multi
UTF8-no-CTL  = %x20-7e / UTF8-multi
UTF8-multi   = %xC0-DF %x80-BF
             / %xE0-EF %x80-BF %x80-BF
             / %xF0-F7 %x80-BF %x80-BF %x80-BF
             / %xF8-FB %x80-BF %x80-BF %x80-BF %x80-BF
             / %xFC-FD %x80-BF %x80-BF %x80-BF %x80-BF %x80-BF

NOTE: The syntax above comes from an older version of UTF-8. It's included so it stays compatible with UTF-8 software built on the earlier specifications. Applications generating this message format SHOULD generate UTF-8 that matches the more restricted specification in RFC 3629 [13] 🌈

4. Header Definitions ✨

This specification defines a core set of headers that applications can use. An application specification must indicate the headers that may be used, those that must be recognized, and those that must appear in any message (see section 6) 🎀

The header definitions that follow fall into two categories:

a) those that are part of the CPIM format extensibility framework, and

b) those that have been based on similar headers in RFC 2822 [9], specified here with corresponding semantics.

Header names and syntax are described without a namespace qualification. The associated namespace URI is listed as part of each header specification. Any of the namespace associations already mentioned (implied default namespace, explicit default namespace, or implied or explicit namespace prefix declaration) may be used to identify the namespace 💜

All headers defined here are associated with the namespace URI <urn:ietf:params:cpim-headers:>, which is defined according to [12].

NOTE: Header names and other text MUST be used as given, using exactly the upper- and lower-case letters shown. On this point, the ABNF used here is different from RFC 2234 [6] 👑

4.1. The 'From' Header

Tells you who sent the message 💌

Header name: From

Namespace URI: <urn:ietf:params:cpim-headers:>

Syntax:

(see also section 3.6)

From-header = "From" ": " [ Formal-name ] "<" URI ">"
                  ; "From" is case-sensitive

Description:

Indicates the sender or originator of a message.

If present, the 'Formal-name' identifies the person or "real world" name for the originator.

The URI indicates an address for the originator.

Examples:

From: Winnie the Pooh <im:pooh@100akerwood.com>

From: <im:tigger@100akerwood.com>

4.2. The 'To' Header

Specifies an intended recipient of a message 🦋

Header name: To

Namespace URI: <urn:ietf:params:cpim-headers:>

Syntax:

(see also section 3.6)

To-header = "To" ": " [ Formal-name ] "<" URI ">"
                  ; "To" is case-sensitive

Description:

Indicates the recipient of a message.

If present, the 'Formal-name' identifies the person or "real world" name for the recipient.

The URI indicates an address for the recipient.

Multiple recipients may be indicated by including multiple 'To' headers.

Examples:

To: Winnie the Pooh <im:pooh@100akerwood.com>

To: <im:tigger@100akerwood.com>

4.3. The 'cc' Header 💌

okay so the cc header is how you send a courtesy copy 💌 aka a non-primary recipient. not the main audience, but still in the loop 👀 literally iconic

Header name: cc

Namespace URI: <urn:ietf:params:cpim-headers:>

Syntax (see also section 3.6)

Cc-header   = "cc" ": " [ Formal-name ] "<" URI ">"
                  ; "cc" is case-sensitive

Description: this one indicates a courtesy copy recipient of a message 🎀

if it's there, the Formal-name is the person's "real world" name for the recipient 🧚 and the URI is their address. you can have multiple courtesy copy recipients by including multiple cc headers, so the whole squad can get cc'd 💖

Examples:

cc: Winnie the Pooh <im:pooh@100akerwood.com>

cc: <im:tigger@100akerwood.com>

---

4.4. The 'DateTime' Header ⏰

this header tells everyone the date and time a message was sent. the timestamp is giving receipts 🧾

Header name: DateTime

Namespace URI: <urn:ietf:params:cpim-headers:>

Syntax (see also section 3.6)

DateTime-header = "DateTime" ": " date-time
                  ; "DateTime" is case-sensitive

(where the syntax of date-time is a profile of ISO8601 [24] defined in "Date and Time on the Internet" [11])

Description: the DateTime header gives the date and time the sender actually sent the message ✨

one big reason this header exists is protection against a replay attack 🔒 because it lets the recipient know when the message was meant to be sent. the value is the sender's current time when the message was transmitted, in ISO 8601 [24] date and time format, as profiled in "Date and Time on the Internet: Timestamps" [11]. no replaying old messages and acting like they're new, bestie 💀

Example:

DateTime: 2001-02-01T12:16:49-05:00

---

4.5. The 'Subject' Header 🌸

this is the topic of the message, the vibe check before anyone opens it 🦋

Header name: Subject

Namespace URI: <urn:ietf:params:cpim-headers:>

Syntax (see also section 3.6)

Subject-header = "Subject" ":" [ ";" Lang-param ] SP *HEADERCHAR
                  ; "Subject" is case-sensitive

Description: the Subject header carries the sender's description of the topic or content of the message 💅

the sending agent should specify the language parameter if it has any reasonable knowledge of the language the sender used for the message subject. so tag the language if you can, it's the polite thing to do 🫶

Example:

Subject:;lang=en Eeyore's feeling very depressed today

---

4.6. The 'NS' Header 🧚

this one is about declaring a local namespace prefix. think of it as giving yourself a nickname that the rest of the message can use 🎀

Header name: NS

Namespace URI: <urn:ietf:params:cpim-headers:>

Syntax (see also section 3.6)

NS-header = "NS" ": " [ Name-prefix ] "<" URI ">"
                  ; "NS" is case-sensitive

Description: the NS header declares a namespace prefix that may be used in subsequent header names. for more details, check section 3.4 🔍

Example:

NS: MyAlias <mid:MessageFeatures@id.foo.com>
MyAlias.MyHeader: private-extension-data

---

4.7. The 'Require' Header 🔥

this header is for when you need the receiver to actually support something or the whole message falls apart 💀 it specifies a header or feature that must be implemented by the receiver for correct message processing.

Header name: Require

Namespace URI: <urn:ietf:params:cpim-headers:>

Syntax (see also section 3.6)

Require-header = "Require" ": " Header-name *( "," Header-name )
                  ; "Require" is case-sensitive

Description: the Require header indicates a header or feature that must be implemented or understood by the receiver for correct message processing. see section 3.5 for more details 🧠

ngl there's one lowkey tip in here. the required header or feature doesn't have to actually be used in the message. but for brevity, it is recommended that an implementation does not issue the Require header for unused features. so don't flex requirements you aren't even using 🙈

Example:

Require: MyAlias.VitalHeader

---

5. Examples 🍓

the examples in the following sections use these per-line tags to show the different parts of the overall message format:

m:  MIME headers for the overall message
s:  a blank separator line
h:  message headers
e:  encapsulated MIME object containing the message content
x:  MIME security multipart message wrapper

the examples also assume <urn:ietf:params:cpim-headers:> is the implied default namespace for the application 💜

5.1. An Example Message/CPIM Message 💌

here's a full Message/CPIM message. this is the moment everything clicks 🤩

m: Content-type: Message/CPIM
s:
h: From: MR SANDERS <im:piglet@100akerwood.com>
h: To: Depressed Donkey <im:eeyore@100akerwood.com>
h: DateTime: 2000-12-13T13:40:00-08:00
h: Subject: the weather will be fine today
h: Subject:;lang=fr beau temps prevu pour aujourd'hui
h: NS: MyFeatures <mid:MessageFeatures@id.foo.com>
h: Require: MyFeatures.VitalMessageOption
h: MyFeatures.VitalMessageOption: Confirmation-requested
h: MyFeatures.WackyMessageOption: Use-silly-font
s:
e: Content-type: text/xml; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: <body>
e: Here is the text of my message.
e: </body>

5.2. An Example Esing MIME multipart/signed 🔐

to secure a Message/CPIM, an application or implementation may use RFC 1847 [14], plus some appropriate security protocols (e.g., S/MIME [19] or openPGP [17]) and a cryptographic scheme. security era, let's gooo 🫶

using S/MIME [19] and pkcs7, the above message would look like this:

x: Content-Type: multipart/signed; boundary=next;
                 micalg=sha1;
                 protocol=application/pkcs7-signature
x:
x: --next
m: Content-Type: Message/CPIM
s:
h: From: MR SANDERS <im:piglet@100akerwood.com>
h: To: Dopey Donkey <im:eeyore@100akerwood.com>
h: DateTime: 2000-12-13T13:40:00-08:00
h: Subject: the weather will be fine today
h: Subject:;lang=fr beau temps prevu pour aujourd'hui
h: NS: MyFeatures <mid:MessageFeatures@id.foo.com>
h: Require: MyFeatures.VitalMessageOption
h: MyFeatures.VitalMessageOption: Confirmation-requested
h: MyFeatures.WackyMessageOption: Use-silly-font
s:
e: Content-type: text/xml; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: <body>
e: Here is the text of my message.
e: </body>
x: --next
x: Content-Type: application/pkcs7-signature
x:
x: (signature stuff)
    :
x: --next--

---

6. Application Design Considerations 🧩

okay so as defined, the 'Message/CPIM' content type uses a default namespace URI urn:ietf:params-cpim-headers:, and it doesn't define any other implicit namespace prefixes 👀 apps with different needs should define and register their own MIME media type, specify the required default namespace URI, and define any implied namespace prefixes as part of that media type spec 📝

applications using this specification must also specify:

• all headers that must be recognized by implementations of the application
• any headers that must be present in all messages created by that application.
• any headers that may appear more than once in a message, and how they are to be interpreted (e.g., how to interpret multiple 'Subject:' headers with different language parameter values).
• security mechanisms and cryptography schemes to be used with the application, including any mandatory-to-implement security provisions.

the goal of a definitive message format that security mechanisms can be applied to puts some real constraints on apps that use it, so pay attention 🔒

• within a network of message transfer agents, an intermediate gateway MUST NOT change the Message/CPIM content in any way. this means headers can't be changed or reordered, transfer encoding can't be changed, languages can't be changed, etc. 🚫
• because Message/CPIM messages are immutable, any transfer agent that wants to modify the message should create a new Message/CPIM message with the modified header and with the original message as its content. (this is kinda like real-world bill-of-lading handling, where each person in the chain attaches a new sheet to the message. then anyone can validate the original message and see what changed and who changed it by following the trail of amendments. another way to picture it is putting the old message in a new envelope 💌)

when choosing security mechanisms for an application, these IAB survey documents may be helpful 📚

• Security Mechanisms for the Internet [28]
• A Survey of Authentication Mechanisms [29].

---

7. IANA Considerations 🌈

this memo calls for two new IANA registrations:

• A new MIME content-type value, Message/CPIM, per RFC 2048 [3]. the registration template can be found in section 7.1 below.
• A new IANA URN sub-namespace, urn:ietf:params:cpim-headers:, per RFC 3553 [12]. the registration template can be found in section 7.2 below.

7.1. Registration for Message/CPIM Content Type 📋

here's the registration template, copied exactly as it's written 🎀

To: ietf-types@iana.org

Subject: Registration of MIME media type Message/CPIM

MIME media type name: message

MIME subtype name: CPIM

Required parameters: (None)

Optional parameters: (None)

Encoding considerations:
   Intended to be used in 8-bit clean environments, with non-
   transformative encoding (8-bit or binary, according to the content
   contained within the message;  the CPIM message headers can be
   handled in an 8-bit text environment).

   This content type could be used with a 7-bit transfer environment
   if appropriate transfer encoding is used.  NOTE that for this
   purpose, enclosed MIME content MUST BE treated as opaque data and
   encoded accordingly.  Any encoding must be reversed before any
   enclosed MIME content can be accessed.

Security considerations:
   The content may contain signed data, so any transfer encoding MUST
   BE exactly reversed before the content is processed.

   See also the security considerations for email messages (RFC 2822
   [9]).

Interoperability considerations:
   This content format is intended to be used to exchange possibly-
   secured messages between different instant messaging protocols.
   Very strict adherence to the message format (including whitespace
   usage) may be needed to achieve interoperability.

Published specification: RFC 3862

Applications which use this media type: Instant messaging
Additional information:
   The default namespace URI associated with this content-type is
   'urn:ietf:params:cpim-headers:'.  (See RFC 3862 for further
   details.)

   See also the Common Profile for Instant Messaging (CPIM) [26].

Person & email address to contact for further information:
   G. Klyne, <GK-IETF@ninebynine.org>

Intended usage: LIMITED USE

Author/Change controller: IETF

7.2. Registration for urn:ietf:params:cpim-headers 🦋

okay so this registry is called cpim-headers 💖. The spec is RFC 3862, and standards track RFCs that update or obsolete RFC 3862 can add more values 🌸.

Repository: http://www.iana.org/assignments/cpim-headers 🔗

Index value: the index value is a CPIM message header name 💅. It can be a sequence from the restricted set of US-ASCII characters we talked about above ✨.

URN Formation: the URI for a header is built from its name in two steps 🧚

• a) any non-URN characters (as defined by RFC 2141 [5]) get swapped for their %hh escape sequence (per RFC 2396 [8]); and
• b) you stick urn:ietf:params:cpim-headers: on the front of the result 🎀

so the URI for the CPIM header From: is urn:ietf:params:cpim-headers:From 💜. The (putative) header Top&Tail ends up as urn:ietf:params:cpim-headers:Top%26Tail 🙈. The & gets escaped because it isn't a URN character, periodt 💀.

---

8. Internationalization Considerations 🌈

message headers use UTF-8 encoding everywhere 💖. That means they can carry the whole UCS-4 (Unicode [30], ISO/IEC 10646 [25]) character repertoire, which is giving global main character energy 👑.

language tagging for message headers is handled by the "Lang" parameter (section 3.3) 🏳️‍🌈 ✨.

message content is any MIME-encapsulated content, so normal MIME internationalization considerations apply to it 🌸.

---

9. Security Considerations 🔐

okay this part is serious bestie 😭. The Message/CPIM format was designed with security in mind 🛡️. It's especially built to work with MIME security multiparts for signatures and encryption 🔏. For that reason, Message/CPIM messages must be considered immutable once they're created 🧊. Nobody gets to edit them after the fact, no cap.

Message/CPIM messages are binary messages, because they use UTF-8 encoding 💀. If they cross transports that aren't 8-bit clean, the transfer agent must tunnel the entire message. Changing the message data encoding is not an option. So the Message/CPIM has to be encapsulated by the message transfer system and unencapsulated at the receiving end of the tunnel 🚇.

the resulting message must not lose any data through the encoding and unencoding process 🫶. For example, an application may choose to apply the MIME base64 content-transfer-encoding to the Message/CPIM object to meet this requirement 🍓.

---

10. Acknowledgements 🎀

the authors thanked these lovely people for their helpful comments 🫶: Harald Alvestrand, Walter Houser, Leslie Daigle, Mark Day, and Brian Raymor 💜.

---

11. References 📚

11.1. Normative References

• [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
• [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
• [3] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
• [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [5] Moats, R., "URN Syntax", RFC 2141, May 1997.
• [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
• [7] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
• [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
• [9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
• [10] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
• [11] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
• [12] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
• [13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

11.2. Informative References

• [14] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
• [15] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M., and P. Svanberg, "The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996", RFC 2130, April 1997.
• [16] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
• [17] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
• [18] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
• [19] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
• [20] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
• [21] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
• [22] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C Recommendation xml, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
• [23] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C Recommendation xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.
• [24] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988.
• [25] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO Standard 10646-1, May 1993.
• [26] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
• [27] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
• [28] Bellovin, S., Kaufman, C., and J. Schiller, "Security Mechanisms for the Internet", RFC 3631, December 2003.
• [29] Rescorla, E., "A Survey of Authentication Mechanisms", Work in Progress, March 2004.
• [30] The Unicode Consortium, "The Unicode Standard, Version 4.0", Addison-Wesley, Boston, MA. ISBN 0-321-18578-1, April 2003, <http://www.unicode.org/unicode/standard/versions/enumeratedversions.html#Unicode_4_0_0>.

---

12. Authors' Addresses 📮

Graham Klyne
Nine by Nine

EMail: GK-IETF@ninebynine.org
URI:   http://www.ninebynine.net/


Derek Atkins
IHTFP Consulting
6 Farragut Ave
Somerville, MA  02144
USA

Phone: +1 617 623 3745
EMail: derek@ihtfp.com, warlord@alum.mit.edu

---

13. Full Copyright Statement ⚖️

the Internet Society owns the copyright here: Copyright (C) The Internet Society (2004). All Rights Reserved. 💜

okay so this document, and translations of it, can be copied and shared with others 🦋. You're also allowed to make derivative works that comment on or explain it, or that help people implement it, and to prepare, copy, publish, and distribute those, in whole or in part, without any restriction at all 🌈. The one catch is that the above copyright notice and this paragraph have to be included on every copy and derivative work 🎀.

however, the document itself may not be modified in any way ✋. That includes removing the copyright notice or the references to the Internet Society or other Internet organizations. The only exceptions are when it's needed to develop Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's translated into languages other than English 🌍.

the limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assignees 💖.

this document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀.

Acknowledgement 🙏

funding for the RFC Editor function is currently provided by the Internet Society 💅✨.