Nine by Nine

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

IHTFP Consulting

6 Farragut Ave Somerville MA 02144 USA +1 617 623 3745 derek@ihtfp.com, warlord@alum.mit.edu

Application message format instant messaging presence IMPP 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 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 . 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.

The Common Profile for Instant Messaging (CPIM) 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 . 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 and CPIM presence 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 for more details.

RFC 2779 requires that an instant message can carry a MIME payload ; 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 , as protocol implementations must already contain code to parse this. Unfortunately, using pure RFC2822/MIME can be problematic: 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 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 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.

This specification aims to satisfy the following goals: a securable end-to-end format for a message (a canonical message format to serve as a basis for signature calculation, rather than specifed 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

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 RFC 2119 . 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.

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

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.

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 , 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: The entire header MUST be contained on a single line. The line terminator is not considered part of the header value. Only one header per line. Multiple headers MUST NOT be included on 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 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 and for the specific syntax). 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. 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 (i.e. "From:" and "from:" are different headers). If a header name is not recognized or not understood, the header should be ignored. But see also the "Require:" header (). 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. 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

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)

When generating messages conformant with this specification: 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). 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. 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.

The final section of a Message/CPIM is the MIME-encapsulated message content, which follows standard MIME formatting rules . 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

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 thoughout, per RFC 3629 . 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. .

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 and HTTP (including HTTP-derived protocols such as SIP ).

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.)

Full internationalization of a protocol requires that a language can be indicated for any human-readable text . 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 .

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' .

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 by XML namespaces . 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 . (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 ), 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 namespace prefixes 'xxx' and 'yyy' are associated with the same namespace URI. Thus the following 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

A 'NS' header without a header prefix name specifies a default namespace for subsequent headers; that is a namespace that is associated with header names not having a prefix. For example: NS: <http://id.acme.widgets/wily-headers/> runner-trap: set has the same meaning as the previous examples.

This framework allows different implementers to create extension headers without the worry of header name duplication; each defines headers within their own namespace.

Sometimes it is necessary for the sender of a message to insist that some functionality is understood by the recipient. By using the mandatory-to-recognize indicator, a sender is notifying the recipient that it MUST understand the named header or feature in order to properly understand the message.

A header or feature is indicated as being mandatory-to-recognize by a 'Require:' header. For example: Require: MyFeatures.VitalMessageOption MyFeatures.VitalMessageOption: Confirmation-requested

Multiple required header names may be listed in a single 'Require' header, separated by commas. NOTE: Indiscriminate use of 'Require:' headers could harm interoperability. It is suggested that any implementer who defines required headers also publish the header specifications so other implementations can successfully interoperate.

The 'Require:' header MAY also be used to indicate that some non-header semantics must be implemented by the recipient, even when it does not appear as a header. For example: Require: Locale.MustRenderKanji might be used to indicate that message content includes characters from the Kanji repertoire, which must be rendered for proper understanding of the message. In this case, the header name is just a token (using header name syntax and namespace association) that indicates some desired behaviour.

The following description of message header syntax uses ABNF, per RFC 2234 . Most of this syntax can be interpreted as defining UCS character sequences or UTF-8 octet sequences. Alternate productions at the end allow for either interpretation. NOTE: Specified text values MUST be used as given, using exactly the indicated upper- and lower-case letters. In this respect, the ABNF usage here differs from RFC 2234 .

Collected syntax: Language-tag = ; 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 = CRLF = SP = DIGIT = HEXDIG = ALPHA = DQUOTE = ]]>

To interpret the syntax in a general UCS character environment, use the following productions: UCS-no-CTL = %x20-7e / UCS-high UCS-high = %x80-ffffffff

To interpret the syntax as defining UTF-8 coded octet sequences, use the following 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

This specification defines a core set of headers that are available for use by applications: 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 ). The header definitions that follow fall into two categories: those that are part of the CPIM format extensibility framework, and those that have been based on similar headers in RFC 2822 , specified here with corresponding semantics. Header names and syntax are described without a namespace qualification, and the associated namespace URI is listed as part of the header specification. Any of the namespace associations already mentioned (implied default namespace, explicit default namespace or implied namespace prefix 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 . NOTE: Header names and other text MUST be used as given, using exactly the indicated upper- and lower-case letters. In this respect, the ABNF usage here differs from RFC 2234 .

Indicates the sender of a message. From <urn:ietf:params:cpim-headers:> (see also )

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

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>

Specifies an intended recipient of a message. To <urn:ietf:params:cpim-headers:> (see also )

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

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>

Specifies a non-primary recipient ("courtesy copy") for a message. cc <urn:ietf:params:cpim-headers:> (see also )

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

Indicates a courtesy copy 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 courtesy copy recipients may be indicated by including multiple 'cc' headers.

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

Specifies the date and time a message was sent. DateTime <urn:ietf:params:cpim-headers:> (see also )

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

(where the syntax of 'date-time' is a profile of ISO8601 defined in "Date and Time on the Internet" ) The 'DateTime' header supplies the date and time at which the sender sent the message. One purpose of the this header is to provide for protection against a replay attack, by allowing the recipient to know when the message was intended to be sent. The value of the date header is the senders's current time when the message was transmitted, using ISO 8601 date and time format as profiled in "Date and Time on the Internet: Timestamps" .

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

Contains a description of the topic of the message. Subject <urn:ietf:params:cpim-headers:> (see also )

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

The 'Subject' header supplies 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 used by the sender to indicate the message subject.

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

Declare a local namespace prefix. NS <urn:ietf:params:cpim-headers:> (see also )

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

Declares a namespace prefix that may be used in subsequent header names. See for more details.

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

Specify a header or feature that must be implemented by the receiver for correct message processing. Require <urn:ietf:params:cpim-headers:> (see also )

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

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. Note that the required header or feature does not have to be used in the message, but for brevity it is recommended that an implementation does not issue the 'Required' header for unused features.

Example: Require: MyAlias.VitalHeader

The examples in the following sections use the per-line tags below to indicate 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 following examples also assume <urn:ietf:params:cpim-headers:> is the implied default namespace for the application.

The following example shows a Message/CPIM message: h: To: Depressed Donkey 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 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: e: Here is the text of my message. e: ]]>

In order to secure a Message/CPIM, an application or implementation may use RFC 1847 , and some appropriate security protocols (e.g. S/MIME or openPGP ), and cryptographic scheme.

Using S/MIME and pkcs7, the above message would look like this: h: To: Dopey Donkey 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 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: e: Here is the text of my message. e: x: --next x: Content-Type: application/pkcs7-signature x: x: (signature stuff) : x: --next-- ]]>

As defined, the 'Message/CPIM' content type uses a default namespace URI 'urn:ietf:params-cpim-headers:', and does not define any other implicit namespace prefixes. Applications that have different requirements should define and register a different MIME media type, specify the required default namespace URI and define any implied namespace prefixes as part of the media type specification. 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 crytography schemes to be used with the application, including any mandatory-to-implement security provisions. The goal of providing a definitive message format to which security mechanisms can be applied places some constraints on the design of applications that use this message format: Within a network of message transfer agents, an intermediate gateway MUST NOT change the Message/CPIM content in any way. This implies that headers cannot be changed or reordered, transfer encoding cannot be changed, languages cannot 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 approach is similar to 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 has changed and who changed it by following the trail of amendments. Another metaphor is including the old message in a new envelope.) In chosing security mechanisms for an applications, the following IAB survey documents may be helpful: Security Mechanisms for the Internet A Survey of Authentication Mechanisms .

This memo calls for two new IANA registrations: A new MIME content-type value, Message/CPIM, per RFC 2048 . The registration template can be found in below. A new IANA URN sub-namespace, urn:ietf:params:cpim-headers:, per RFC 3553 . The registration template can be found in below.

ietf-types@iana.org Registration of MIME media type Message/CPIM message CPIM (None) (None) 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. 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 ). 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. RFC &rfc.number; Instant messaging The default namespace URI associated with this content-type is 'urn:ietf:params:cpim-headers:'. (See RFC &rfc.number; for further details.) See also the Common Profile for Instant Messaging (CPIM) . G. Klyne, <GK-IETF@ninebynine.org> LIMITED USE IETF

cpim-headers RFC &rfc.number;. Additional values may be defined by standards track RFCs that update or obsolete RFC &rfc.number;. http://www.iana.org/assignments/params/YYYY [[[to be defined]]] The index value is a CPIM message header name, which may consist of a sequence from a restricted set of US-ASCII characters, as defined above. The URI for a header is formed from its name by: replacing any non-URN characters (as defined by RFC 2141 ) with the corresponding '%hh' escape sequence (per RFC 2396 ); and prepending the resulting string with 'urn:ietf:params:cpim-headers:'. Thus, the URI corresponding to the CPIM message header 'From:' would be 'urn:ietf:params:cpim-headers:From'. The URI corresponding to the (putative) CPIM message header 'Top&Tail' would be 'urn:ietf:params:cpim-headers:Top%26Tail'.

Message headers use UTF-8 character encoding throughout; hence, they can convey the full UCS-4 (Unicode , ISO/IEC 10646 ) character repertoire. Language tagging is provided for message headers using the "Language" parameter. Message content is any MIME-encapsulated content, and normal MIME content internationalization considerations apply.

The Message/CPIM format is designed with security in mind. In particular it is designed to be used with MIME security multiparts for signatures and encryption. To this end, Message/CPIM messages must be considered immutable once created. Because Message/CPIM messages are binary messages (due to UTF-8 encoding), if they are transmitted across non-8-bit-clean transports then the transfer agent must tunnel the entire message. Changing the message data encoding is not an option. This implies that the Message/CPIM must be encapsulated by the message transfer system and unencapsulated at the receiving end of the tunnel. The resulting message must not have data loss due to the encoding and unencoding of the message. For example, an application may choose to apply the MIME base64 content-transfer-encoding to the Message/CPIM object to meet this requirement.

The authors thank the following for their helpful comments: Harald Alvestrand, Walter Houser, Leslie Daigle, Mark Day, Brian Raymor.

The Unicode Consortium

[[[RFC editor: please remove this section on final publication]]] Fold in changes from diff file provided by RFC Editor. Add (informative) references for Unicode and ISO/IEC 10646. Fix up text of note about the 'Required' header. Add forward reference in to header name syntax sections. Updated citations of RFC 2279 to RFC 3629. Removed reference to RFC 2278. Added citation of ISO8601 in description of DateTime header. Added some ?RFC needLines...? directives to avoid break-up of examples, etc. Document source converted to XML2RFC format; this has a number of effects on layout. References renumbered due to the change to XML2RFC. Changed reference to RFC 3553 (IETF URN Sub-namespace for Registered Protocol Parameters). Reference current work-in-progress draft-ietf-impp-im rather than the very much older draft-ietf-impp-cpim. Add reference to draft-ietf-impp-pres. Add normative reference to RFC2026. Added note that applications must define appropriate mechanisms as required to secure message content. Changed syntax to use DQUOTE rather than <">. Add additional warning about case sensitive use of ABNF. Add some comments emphasizing that security details need to be part of the application design. Add some security-related informative references. Editorial rework of overall message structure description at start of section 2. Change author affiliation and email details. Update document and expiry dates, for re-realease of I-D post- last-call. Separate normative and informative references. Change author affiliation details. Update document and expiry dates, for re-realease of I-D. Update date-time reference to RFC3339. Fix description of 'require' header in section 4.7. Fix definition in section 3.6 of NAMECHAR characters to include apostrophe 0x27 (following RFC 2822). Fix error in sect 3.1 definition of SEPARATORS. Various editorial changes in response to last-call comments: more consistent reference to RFC2822/MIME message format; slightly expanded comment on problems with X-headers; softened wording about use of Java escape mechanism to make it clearer that Java is not a normative reference here; revised phrasing of first paragraph of section 3; correct other typos. Fix typos. Complete change of 'Date:' header to 'DateTime:'. Updated author affiliations. Fix up multipart/signed example. Add registration templates for Message/CPIM content type, and urn:ietf:params:cpim-headers: URN space. Update namespace identifier. Revised application design considerations to indicate that a default namespace URI and any implicit prefixes are to be specified by the MIME media type specification. Noted variation of ABNF usage from RFC 2234 (exact case only). Add reference to URN syntax (RFC 2141). Tighten up application of escape sequences. Updated reference to date/time draft. Editorial changes. State explicitly that unrecognized header names should be ignored. Remove text about (non)significance of header order: simply say that order must be preserved. Incorporate review comments. State (simply) that this is a canonical end-to-end format for the purpose of signature calculation. Defined escape mechanism for control characters. Header name parameters placed after the ":". Changed name of Date: header to DateTime:. Revised syntax to separate character-level syntax from UTF-8 octet- level syntax. Folded in some review comments. Fix up some syntax problems. Other small editorial changes. Add some references. Editorial review. Reworked namespace framework description. Deferred specification of mandatory headers to the application specification, allowing this document to be less application-dependent. Expanded references. Replaced some text with ABNF syntax descriptions. Reordered some major sections. Memo initially created.

[[[RFC editor: please remove this section on final publication]]] Update references to other CPIM documents . Remove revision history and TODO list Finalize RFC number and attributes on <rfc ... > element. Replace XXXX, YYYY with appropriate values. Finalize location of repository for members of urn:ietf:params:cpim-headers sub-namespace. Finalize publication date.