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.
3.5. Mandatory-to-Recognize Features
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.
3.6. Collected Message Header Syntax
The following description of message header syntax uses ABNF, per RFC
2234 [6]. 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 [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 interpret the syntax in a general UCS character environment, use
the following productions:
UCS-no-CTL = %x20-7e / UCS-high
UCS-high = %x80-7fffffff
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
NOTE: the above syntax comes from an older version of UTF-8, and is
included for compatibility with UTF-8 software based 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 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 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, 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 [12].
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 [6].
4.1. The ’From’ Header
Indicates the sender of a 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
Specifies a non-primary recipient ("courtesy copy") for a message.
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:
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>
4.4. The ’DateTime’ Header
Specifies the date and time a message was sent.
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 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 [24] date and time format as profiled in "Date and
Time on the Internet: Timestamps" [11].
Example:
DateTime: 2001-02-01T12:16:49-05:00
4.5. The ’Subject’ Header
Contains a description of the topic of the message.
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 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
4.6. The ’NS’ Header
Declare a local namespace prefix.
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:
Declares a namespace prefix that may be used in subsequent header
names. See section 3.4 for more details.
Example:
NS: MyAlias <mid:MessageFeatures@id.foo.com>
MyAlias.MyHeader: private-extension-data
4.7. The ’Require’ Header
Specify 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:
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
5. Examples
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.
5.1. An Example Message/CPIM Message
The following example shows a Message/CPIM message:
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
In order to secure a Message/CPIM, an application or implementation
may use RFC 1847 [14], and some appropriate security protocols (e.g.,
S/MIME [19] or openPGP [17]), and cryptographic scheme.
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
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:
o all headers that must be recognized by implementations of the
application
o any headers that must be present in all messages created by that
application.
o 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).
o 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:
o 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.
o 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:
o Security Mechanisms for the Internet [28]
o A Survey of Authentication Mechanisms [29].
7. IANA Considerations
This memo calls for two new IANA registrations:
o A new MIME content-type value, Message/CPIM, per RFC 2048 [3].
The registration template can be found in section 7.1 below.
o 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
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
Registry name: cpim-headers
Specification:
RFC 3862. Additional values may be defined by standards track
RFCs that update or obsolete RFC 3862.
Repository:
http://www.iana.org/assignments/cpim-headers
Index value:
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.
URN Formation:
The URI for a header is formed from its name by:
a) replacing any non-URN characters (as defined by RFC 2141 [5])
with the corresponding ’%hh’ escape sequence (per RFC 2396
[8]); and
b) 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’.
8. Internationalization Considerations
Message headers use UTF-8 character encoding throughout; hence, they
can convey the full UCS-4 (Unicode [30], ISO/IEC 10646 [25])
character repertoire.
Language tagging is provided for message headers using the "Lang"
parameter (section 3.3).
Message content is any MIME-encapsulated content, and normal MIME
content internationalization considerations apply.
9. Security Considerations
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.
10. Acknowledgements
The authors thank the following for their helpful comments: Harald
Alvestrand, Walter Houser, Leslie Daigle, Mark Day, 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