Request for Comments: 3862 Nine by Nine
Category: Standards Track D. Atkins
IHTFP Consulting
August 2004
Common Presence and Instant Messaging (CPIM): Message Format
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
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.
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
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. This is a common message format for
CPIM-compliant messaging protocols [26].
While being prepared for CPIM, this format is quite general and may
be reused by other applications with similar requirements.
Application specifications that adopt this as a base format should
address the questions raised in section 6 of this document.
1.1. Motivation
The Common Profile for Instant Messaging (CPIM) [26] specification
defines a number of operations to be supported and criteria to be
satisfied for interworking between diverse instant messaging
protocols. The intent is to allow a variety of different protocols
interworking through gateways to support cross-protocol messaging
that meets the requirements of RFC 2779 [20].
To adequately meet the security requirements of RFC 2779, a common
message format is needed so that end-to-end signatures and encryption
may be applied. This document describes a common canonical message
format that must be used by any CPIM-compliant message transfer
protocol, whereby signatures are calculated for end-to-end security.
The design of this message format is intended to enable security to
be applied, while itself remaining agnostic about the specific
security mechanisms that may be appropriate for a given application.
For CPIM instant messaging and presence, specific security protocols
are specified by the CPIM instant messaging [26] and CPIM presence
[27] specifications.
Also note that the message format described here is not itself a MIME
data format, although it may be contained within a MIME object, and
may contain MIME objects. See section 2 for more details.
1.2. Background
RFC 2779 requires that an instant message can carry a MIME payload
[1][2]; thus some level of support for MIME will be a common element
of any CPIM compliant protocol. Therefore it seems reasonable that a
common message format should use a RFC2822/MIME-like syntax [9], as
protocol implementations must already contain code to parse this.
Unfortunately, using pure RFC2822/MIME can be problematic:
o 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.
o 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.
o 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.
o Message and payload separation -- there is not a clear syntactic
distinction between message metadata and message content.
o 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.)
o No support for structured information (text string values only).
o Some processors impose line length limitations.
The message format defined by this memo overcomes some of these
difficulties by having a simplified syntax that is generally
compatible with the format accepted by RFC2822/MIME parsers and
having a stricter syntax. It also defines mechanisms to support some
desired features not covered by the RFC2822/MIME format
specifications.
1.3. Goals
This specification aims to satisfy the following goals:
o 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).
o independence of any specific application
o capability of conveying a range of different address types
o assumption of an 8-bit clean message-transfer protocol
o evolvable: extensible by multiple parties
o a clear separation of message metadata from message content
o a simple, regular, easily parsed syntax
o a compact, low-overhead format for simple messages
1.4. Terminology and Conventions
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
The CPIM message format encapsulates arbitrary MIME message content,
together with message- and content-related metadata. This can
optionally be signed or encrypted using MIME security multiparts in
conjunction with an appropriate security scheme.
A Message/CPIM object is a two-part entity, where the first part
contains the message metadata and the second part is the message
content. The two parts are separated from the enclosing MIME header
fields and also from each other by blank lines. The message metadata
header information obeys more stringent syntax rules than the MIME
message content headers that may be carried within 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
the protocol used. The tags ’m:’, ’s:’, ’h:’, ’e:’, and ’x:’ are not
part of the message format and are used here to indicate the
different parts of the message, thus:
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 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
Message headers carry information relevant to the end-to-end transfer
of the message from sender to receiver. 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.
The message headers serve a similar purpose to RFC 2822 message
headers in email [9], and have a similar but restricted allowable
syntax.
The basic header syntax is:
Key: Value
where "Key" is a header name and "Value" is the corresponding header
value.
The following considerations apply:
o The entire header MUST be contained on a single line. The line
terminator is not considered part of the header value.
o Only one header per line. Multiple headers MUST NOT be included
on a single line.
o Processors SHOULD NOT impose any line-length limitations.
o There MUST NOT be any whitespace at the beginning or end of a
line.
o UTF-8 character encoding [13] MUST be used throughout.
o The character sequence CR,LF (13,10) MUST be used to terminate
each line.
o The header name contains only US-ASCII characters (see section 3.1
and section 3.6 for the specific syntax).
o The header MUST NOT contain any control characters (0-31). If a
header value needs to represent control characters then the escape
mechanism described below MUST be used.
o There MUST be a single space character (32) following the header
name and colon.
o Multiple headers using the same key (header name) are allowed.
(Specific header semantics may dictate only one occurrence of any
particular header.)
o Header names MUST match exactly (i.e., "From:" and "from:" are
different headers).
o If a header name is not recognized or not understood, the header
should be ignored. But see also the "Require:" header (section
4.7).
o Interpretation (e.g., equivalence) of header values is dependent
on the particular header definition. Message processors MUST
preserve all octets of all headers (both name and value) exactly.
o Message processors MUST NOT change the order of message headers.
Examples:
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,
having Unicode code points in the range U+0000 to U+001f or U+007f.
(Rather than invent something completely new, the escape mechanism
has been adopted from that used by the Java programming language.)
Note that the escape mechanism is applied to a UCS-2 character, NOT
to the octets of its UTF-8 coding. Mapping from/to UTF-8 coding is
performed without regard for escape sequences or character coding.
(The header syntax is defined so that octets corresponding to control
characters other than CR and LF do not appear in the output.)
An arbitrary UCS-2 character is escaped using the 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.
Further, the following special sequences introduced by "\" are used:
\\ 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 conformant with this specification:
o The special sequences listed above MUST be used to encode any
occurrence of the following characters that appear anywhere in a
header: backslash (U+005c), backspace (U+0008), tab (U+0009),
linefeed (U+000a) or carriage return (U+000d).
o The special sequence \" MUST be used for any occurrence of a
double quote (U+0022) that appears within a string delimited by
double quotes.
o The special sequence \’ MUST be used for any occurrence of a
single quote (U+0027) that appears within a string delimited by
single quotes.
o Single- or double-quote characters that delimit a string value
MUST NOT be escaped.
o 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.
o 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.
Further, any other occurrence of an escape sequence described above
SHOULD be recognized and treated as an occurrence of 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 may be any MIME type.
Example:
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 contains two parts, a name and a value, separated by a colon
character (’:’) and single space (32). It is terminated by 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. Use of the character "." in
a header name is reserved for a namespace prefix separator.
Separator characters are:
SEPARATORS = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / DQUOTE
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP
NOTE: The range of allowed characters was determined by examination
of HTTP and RFC 2822 header name formats and choosing the more
restricted. The intent is to allow CPIM headers to follow a syntax
that is compatible 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 the corresponding header
specification. Implementations that use a particular header must
adhere to the format and usage rules thus defined 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 including
’;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 is not applied a header, any human-readable
text is assumed to use the language identified as ’i-default’ [7].
3.4. Namespaces for Header Name Extensibility
NOTE: This section defines a framework for header extensibility whose
use is optional. If no header extensions are allowed by an
application then these structures may never be used.
An application that uses this message format is expected to define
the set of headers that are required and allowed for that
application. This section defines a header extensibility framework
that can be used with any application.
The extensibility framework is based on that provided for XML [22] by
XML namespaces [23]. All headers are associated with a "namespace",
which is in turn associated with a globally unique URI.
Within a particular message instance, header names are associated
with a particular namespace through the presence or absence of a
namespace prefix, which is a leading part of the header name followed
by a period ("."); e.g.,
prefix.header-name: header-value
Here, ’prefix’ is the header name prefix, ’header-name’ is the header
name within the namespace associated with ’prefix’, and ’header-
value’ is the value for this header.
header-name: header-value
In this case, the header name prefix is absent, and the given
’header-name’ is associated with a default namespace.
The Message/CPIM media type registration designates a default
namespace for any headers that are not more explicitly associated
with any namespace. In most cases, this default namespace is all
that is needed.
A namespace is identified by a URI. In this usage, the URI is used
simply as a globally unique identifier, and there is no requirement
that it can be used for any other purpose. Any legal globally unique
URI MAY be used to identify a namespace. (By "globally unique", we
mean constructed according to some set of rules so that it is
reasonable to expect that nobody else will use the same URI for a
different purpose.) 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 is used to declare a
namespace prefix and associate it with a URI that identifies a
namespace. Following that declaration, within the scope of that
message, the combination of namespace prefix and header name
indicates a globally unique identifier for the header (consisting of
the namespace URI and header name).
For example:
NS: MyFeatures <mid:MessageFeatures@id.foo.com>
MyFeatures.WackyMessageOption: Use-silly-font
This defines a namespace prefix ’MyFeatures’ associated with the
namespace identifier ’mid:MessageFeatures@id.foo.com’. Subsequently,
the prefix indicates that the WackyMessageOption header name
referenced is associated with the identified namespace.
A namespace prefix declaration MUST precede any use of that prefix.
With the exception of any application-specific predefined namespace
prefixes (see section 6), a namespace prefix is strictly local to the
message in which it occurs. The actual prefix used has no global
significance. This means that the headers:
xxx.name: value
yyy.name: value
in two different messages may have exactly the same effect if