IETF impp WG Derek Atkins, Telcordia Technologies
Internet draft Graham Klyne, Baltimore Technologies
7 February 2001
Expires: August 2001
Common Presence and Instant Messaging Message Format
<draft-ietf-impp-cpim-msgfmt-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
West Coast).
Copyright Notice
Copyright (C) The Internet Society 2001. All Rights Reserved.
Abstract
This memo defines the mime type 'message/cpim', a message format
for protocols that conform to the Common Profile for Instant
Messaging (CPIM) specification.
Discussion of this document
Please send comments to: <impp@iastate.edu>.
To subscribe: send a message with the body 'subscribe' to <impp-
request@iastate.edu>. The mailing list archive is at
<http://www.imppwg.org>.
Atkins & Klyne Internet draft [Page 1]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
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 Message content ......................................7
3. MESSAGE HEADER SYNTAX....................................8
3.1 Header names .........................................8
3.2 Header Value .........................................8
3.3 Language Tagging .....................................9
3.4 Namespaces for header name extensibility .............9
3.5 Mandatory-to-recognize features ......................11
3.6 Collected message header syntax ......................12
4. HEADER DEFINITIONS.......................................13
4.1 The 'From' header ....................................14
4.2 The 'To' header ......................................15
4.3 The 'cc' header ......................................16
4.4 The 'Date' header ....................................16
4.4.1 ISO 8601 date-and-time format....................17
4.5 The 'Subject' header .................................18
4.6 The 'NS' header ......................................18
4.7 The 'Require' header .................................19
5. EXAMPLES.................................................19
5.1 An example message/cpim message ......................20
5.2 An example using MIME multipart/signed ...............20
6. APPLICATION DESIGN CONSIDERATIONS........................21
7. IANA CONSIDERATIONS......................................22
8. INTERNATIONALIZATION CONSIDERATIONS......................22
9. SECURITY CONSIDERATIONS..................................22
10. REFERENCES..............................................23
11. AUTHORS' ADDRESSES......................................25
Appendix A: Amendment history...............................25
Full copyright statement....................................26
Atkins & Klyne Internet draft [Page 2]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
1. INTRODUCTION
This memo defines the mime content-type 'message/cpim. This is a
common message format for CPIM-compliant instant messaging
protocols [14].
While being prepared for CPIM, this format is quite general and may
be reused by other applications with similar requirements.
1.1 Motivation
The Common Profile for Instant Messaging (CPIM) [14] specification
defines a number of operations to be supported and criteria to be
satisfied for interworking diverse instant messaging protocols.
The intent is to allow a veriety of different protocols
interworking through gateways to support cross-protocol messaging
that meets the requirements of RFC 2779 [15].
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
message format that must be used by any CPIM-compliant message
transfer protocol.
Also, because CPIM is a set of functional requirements, not a
specific protocol, some different format may be used when actually
sending a message; in such cases, the format defined here defines
a basis for computing hash values for passing digital signatures
between different CPIM-compliant protocols.
1.2 Background
RFC 2779 requires that an instant message can carry a MIME payload
[3,4]; 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 MIME/RFC822
syntax, as protocol implementations must already contain code to
parse this.
Unfortunately, using pure RFC822/MIME [2] can be problematic:
o Irregular lexical structure -- RFC822 allows a number of optional
encodings and multiple ways to encode a particular value. For
example RFC822 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.
Atkins & Klyne Internet draft [Page 3]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
o Weak internationalization -- RFC822 requires header values to use
7-bit ASCII, which is problematic for encoding international
character sets. Mechanisms for language tagging in RFC822
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 attempt at achieving security (e.g. signatures), leaving
receiving applications unable to verify the received data.
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).
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 syntax that is generally compatible with
the format accepted by MIME/RFC822 parsers, but simplified, and
having a stricter syntax. It also defines mechanisms to support
some desired features not covered by the RFC822/MIME format
specifications.
1.3 Goals
This specification aims to satisfy the following goals:
o a securable end-to-end format for a message
o independent of any specific application
o capable of conveying a range of different address types
o assumes an 8-bit clean message-transfer protocol
o evolvable: extensible by multiple parties
o to clearly separate message metadata from message content
o a simple, regular, easily parsed syntax
o a compact, low-overhead format for simple messages
[[[Some message transfer protocols may choose (unwisely) to use
their own proprietary formats on-the-wire. A goal of the
Atkins & Klyne Internet draft [Page 4]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
message/cpim format is to enable such protocols to generate a
canonical format on-the-fly for security or transfer to another
protocol.]]]
[[[A very strict syntax is necessary to limit the amount of extra
data that message tranfer protocols need to re-create a
message/cpim message (e.g. for signature verification). If
multiple spaces are allowed, then a transfer protocol would need to
keep the context for the number of spaces used between the key and
value.]]]
1.4 Terminology and conventions
[[[Standard stuff about RFC 2119]]]
2. OVERALL MESSAGE STRUCTURE
The message/cpim format encapsulates an 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 multipart entity, where the first part
contains the message metadata and the second part is the message
content. The two parts are syntactically separated by a blank
line, to keep the message header information (with its more
stringent syntax rules) separate from the MIME message content
headers.
The message/cpim format is a MIME object containing two parts:
message headers (metadata) and message content, separated by a
blank line.
Thus, the complete message looks something like this:
m: Content-type: message/cpim
s:
h: (message-metadata-headers)
s:
e: (encapsulated MIME message-body)
Atkins & Klyne Internet draft [Page 5]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
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 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 of the message from sender to receiver.
Message headers MUST NOT be modified or reformatted in transit, but
in some circumstances they MAY be examined by a CPIM message
transfer protocol.
The message headers serve a similar purpose to RFC822 message
headers in email [2], 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.
Atkins & Klyne Internet draft [Page 6]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
o UTF-8 character encoding [21] 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 later 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 a
suitable escape mechanism must be defined.
[[[???define a standard escape mechanism??? If so, what about
URIs, and other objects with their own defined mechanisms???]]]
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 Headers names are case-sensitive.
o Case-sensitivity of the header values are dependent on the
particular header definition. Message processors MUST preserve
the case of all headers (both the header name and header value).
o The order of headers is not generally significant, except
possibly where there are multiple occurrences of a given header
name. Message processors MUST preserve the ordering of message
headers.
Examples:
To: Pooh Bear <im:pooh@100akerwood.com>
From: <im:piglet@100akerwood.com>
Date: 2001-02-02T10:48:54-05:00
2.3 Message content
The final section of a message/cpim is the MIME-encapsulated
message content, which follows standard MIME formatting rules
[3,4].
The MIME content headers MUST include at least a Content-Type
header. The content may be any MIME type.
Atkins & Klyne Internet draft [Page 7]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
Example:
Content-Type: text/plain; charset=utf-8
Content-ID: <1234567890@foo.com>
This is my encapsulated text message content
3. MESSAGE HEADER SYNTAX
A header is made of two parts, a name and a value, separated by a
colon character (':') followed by a single space (32), and
terminated by a sequence of CR,LF (13,10).
Headers use UTF-8 character encoding thoughout, per RFC 2279 [21].
3.1 Header names
The header name is a sequence of US-ASCII characters, excluding
control characters, SPACE or separator characters. Use of the
character "." in a header name is reserved for a namespace prefix
separator.
Separator characters are:
SEPARATORS = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP
NOTE: the range of allowed characters was determined by
examination of HTTP and RFC822 header name formats and
choosing the more resticted. The intent is to allow CPIM
headers to follow a syntax that is compatible with the
allowed syntax for both RFC 822 [2] and HTTP [18]
(including HTTP-derived protocols such as SIP).
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 hjeader formats MUST also be
followed (one line, UTF-8 character encoding, no control
characters, etc.)
Atkins & Klyne Internet draft [Page 8]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
3.3 Language Tagging
Full internationalization of a protocol requires that a language
can be indicated for any human-readable text [6,19].
A message header may indicate a language for the associated value
by including a language parameter ';lang=tag' after the header name
and preceding the colon, where 'tag' is a language identifying
token per RFC 3066 [7].
Example:
Subject;lang=fr: Subjet 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' [19].
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 [11]
by XML namespaces [12]. 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.
Atkins & Klyne Internet draft [Page 9]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
An application that uses this format designates a default namespace
for any headers that are not more explicitly associated with any
namespace. In many cases, the default namespace may be 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 [10]. (Relative URIs and URI-
references containing fragment identifiers MUST NOT be used for
this purpose.)
Within a specific message, a '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.
Atkins & Klyne Internet draft [Page 10]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
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. Thus, 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/wiley-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/wiley-headers/>
runner-trap: set
has the same meaning as the previous examples.
This framework allows different implementors 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.
Atkins & Klyne Internet draft [Page 11]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
Note that indiscriminate use of required headers could harm
interoperability. It is suggested that any implementator who
defines required headers also publish the header specifications so
other implementations can succesfully 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 [17].
Header = Header-name *( ";" Parameter ) ": "
Header-value
CRLF
Header-name = [ Name-prefix "." ] Name
Name-prefix = Token
Name = Token
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 = *UTF8-no-CTL
Token = 1*TOKENCHAR
Number = 1*DIGIT
String = DQUOTE *( Str-char / Esc-pair ) DQUOTE
Str-char = ( %x20-21 / %x23-5B / %x5D-7E / UTF8-multi )
Esc-pair = "\" UTF8-no-CTL
Atkins & Klyne Internet draft [Page 12]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
Formal-name = 1*( Token SP ) / String
URI = <defined as absolute-URI by RFC 2396>
Language-tag = <defined by RFC 3066>
TOKENCHAR = <Any character except CTLs or SEPARATORS or ".">
SEPARATORS = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP
CTL = <Defined by RFC 2234 -- %x0-%x17, %x7f>
CRLF = <Defined by RFC 2234 -- CR, LF>
SP = <defined by RFC 2234 -- %x20>
DIGIT = <defined by RFC 2234 -- '0'-'9'>
DQUOTE = <defined by RFC 2234 -- %x22>
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
4. HEADER DEFINITIONS
This specification defines a core set of headers that may be used
by CPIM applications: the application specification must indicate
the headers that may be used, those that must be recognized and
those that must be appear in any message.
[[[This means that the CPIM core specification must list the
headers that are needed and allowed for CPIM]]]
The header definitions that follow fall into two categories:
(a) those that are part of the CPIM format extensibility
framework, with header name prefix CPIM.
(b) some that have been based on similar headers in RFC 822,
specified here with corresponding semantics.
Header names and syntax are given without a namespace
qualification, and the associated namespace URI is listed as part
of the header description. 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:iana:cpim-headers]]]>, which is defined according to [22].
Atkins & Klyne Internet draft [Page 13]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
4.1 The 'From' header
Indicates the sender of a message.
Header name: From
Namespace URI: <[[[urn:iana:cpim-headers]]]>
Syntax: (see also section 3.6)
From-header = "From" ": " [ Formal-name ] "<" URI ">"
Description:
Indicates the sender or originator of a message.
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>
Atkins & Klyne Internet draft [Page 14]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
4.2 The 'To' header
Specifies an intended recipient of a message.
Header name: To
Namespace URI: <[[[urn:iana:cpim-headers]]]>
Syntax: (see also section 3.6)
To-header = "To" ": " [ Formal-name ] "<" URI ">"
Description:
Indicates the recipient of a message.
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>
Atkins & Klyne Internet draft [Page 15]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
4.3 The 'cc' header
Specifies a non-primary recipient ("courtesy copy") for a message.
Header name: cc
Namespace URI: <[[[urn:iana:cpim-headers]]]>
Syntax: (see also section 3.6)
Cc-header = "cc" ": " [ Formal-name ] "<" URI ">"
Description:
Indicates a courtesy copy recipient of a message.
The 'Formal-name', if present, 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 'Date' header
Specifies the date and time a message was sent.
Header name: Date
Namespace URI: <[[[urn:iana:cpim-headers]]]>
Syntax: (see also section 8.4.1 below)
Date-header = "Date" ": " date-time
Description:
The 'Date' header supplies the current 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
Atkins & Klyne Internet draft [Page 16]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
header is the current time at the sender when the message was
transmitted, using ISO 8601 date and time format as defined in
section 8.4.1 below.
Example:
Date: 2001-02-01T12:16:49-05:00
4.4.1 ISO 8601 date-and-time format
[[[Suggest RFC-publishing and citing Chris Newman's time-and-date
draft, from where this was lifted.]]]
The following profiles ISO 8601 [13] dates, using ABNF [17]:
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30 or 01-31
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-59 or 00-60
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second
[time-secfrac]
full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset
date-time = full-date "T" full-time
Atkins & Klyne Internet draft [Page 17]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
4.5 The 'Subject' header
Contains a description of the topic of the message.
Header name: Subject
Namespace URI: <[[[urn:iana:cpim-headers]]]>
Syntax: (see also section 3.6)
Subject-header = "Subject" [ lang-param ] ": " *UTF8-no-CTL
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
describe the message.
Example:
Subject;lang=en: Eeyore's feeling very depressed today
4.6 The 'NS' header
The "NS" header is used to declare a local namespace prefix.
Header name: NS
Namespace URI: <[[[urn:iana:cpim-headers]]]>
Syntax: (see also section 3.6)
NS-header = "NS" ": " [ Name-prefix ] "<" URI ">"
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>
Atkins & Klyne Internet draft [Page 18]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
4.7 The 'Require' header
Specify a header or feature that must be implemented by the
receiver for correct message processing.
Header name: NS
Namespace URI: <[[[urn:iana:cpim-headers]]]>
Syntax: (see also section 3.6)
Require-header = "Require" ": " Header-name *( "," Header-name )
Description:
Declares a namespace prefix that may be used in subsequent header
names. See section 3.5 for more details.
Note that there is no requirement that the required header
actually be used, but for brevity it is recommended that an
implemention not use issue require header for unused headers.
Example:
Require: MyAlias.VitalHeader
5. EXAMPLES
The examples in the following sections use the following per-line
tags 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 that <[[[urn:iana:cpim-
headers]]]> is the implied default namespace for the application
concerned.
Atkins & Klyne Internet draft [Page 19]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
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: Dopey Donkey <im:eeyore@100akerwood.com>
h: Date: 2000-12-13T13:40:00-08:00
h: Subject: Message subject
h: Subject;lang=fr: Subjet de message
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 using MIME multipart/signed
In order to secure a message/cpim, an application or implementation
should use RFC 1847 and some appropriate cryptographic scheme.
Atkins & Klyne Internet draft [Page 20]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
Using S/MIME and pkcs7, the above message would look like this:
x: Content-Type: multipart/signed; boundary=next;
MDALG=SHA-1; type=application/pkcs
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: Date: 2000-12-13T13:40:00-08:00
h: Subject: Message subject
h: Subject;lang=fr: Subjet de message
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
x:
x: (signature stuff)
:
x: --next--
6. APPLICATION DESIGN CONSIDERATIONS
Applications using the specification must specify:
o a default namespace for messages created and processed by that
application
o any namespace prefixes (in addition to CPIM) that are implicitly
defined for messages created and processed by that application
o all headers that must be recognized by implementations of the
application
o any headers that must be present in messages created by that
application
Within a network of message transfer agents, an intermediate
gateway MUST NOT change the message/cpim content in any way. This
Atkins & Klyne Internet draft [Page 21]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
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 containing 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 was changed and who changed it by following
the trail of amendments. Another metaphor is including the old
message in a new envelope.)
7. IANA CONSIDERATIONS
[[[Registration template for message/cpim content type]]]
[[[Registration of namespace URN for CPIM headers]]]
8. INTERNATIONALIZATION CONSIDERATIONS
Message headers use UTF character encoding throughout, so can
convey the full UCS-4 (Unicode) character repertoire.
Language tagging is provided for message headers.
Message content is any MIME-ancapsulated 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 transfer encoding is not an allowable option. This
implies that the message/cpim must be encapsulated by the message
tranfer system and unencapsulated at the receiving end of the
tunnel.
The resulting message must have zero data loss due to the encoding
and unencoding of the message. For example, an application may
Atkins & Klyne Internet draft [Page 22]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
choose to apply the MIME base64 content-transfer-encoding to the
message/cpim object to meet this requirement.
10. REFERENCES
[1] Bradner, S.,
"Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119,
March 1997.
[2] Crocker, D.,
"Standard for the format of ARPA Internet text messages",
RFC 822, STD 11,
August 1982.
[3] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions (MIME) Part One: Format of
Internet Message Bodies",
RFC 2045,
November 1996.
[4] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types",
RFC 2046
November 1996.
[5] Freed, N., Klensin, J., and J. Postel,
"Multipurpose Internet Mail Extensions (MIME) Part Four:
Registration Procedures",
RFC 2048, BCP 13,
November 1996.
[6] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson,
R., Crispin, M., Svanberg, P.,
"Report from the IAB Character Set Workshop",
RFC 2130,
April 1997.
[7] Alvestrand, H.,
"Tags for the Identification of Languages",
RFC 3066,
January 2001.
(Defines Content-language header.)
[8] Ramsdell, B.,
"S/MIME Version 3 Message Specification",
RFC 2633,
June 1999.
Atkins & Klyne Internet draft [Page 23]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
[9] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
"OpenPGP Message Format",
RFC 2440,
November 1998.
[10] Berners-Lee, T., Fielding, R.T. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396,
August 1998.
[11] Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen,
"Extensible Markup Language (XML) 1.0",
W3C recommendation: <http://www.w3.org/TR/REC-xml>,
10 February 1998.
[12] Tim Bray, Dave Hollander, and Andrew Layman
"Namespaces in XML",
W3C recommendation: <http://www.w3.org/TR/REC-xml-names>,
14 January 1999.
[13] "Data elements and interchange formats _
Information interchange _ Representation of dates and times"
ISO 8601:1988(E)
International Organization for Standardization
June 1988.
[14] CPIM
[15] RFC 2779: IMPP requirements
[16] RFC 2231: MIME extensions for language tagging
[17] RFC 2234: ABNF
[18] RFC 2616: HTTP/1.1
[19] Alvestrand, H,
"IETF Policy on Character Sets and Languages",
RFC 2277, BCP 18,
January 1998.
[20] Freed, N., and J. Postel,
"IANA Charset Registration Procedures",
BCP 19, RFC 2278,
January 1998.
[21] RFC 2279, UTF-8
[22] IANA URN namespace: work-in-progress proposal
Atkins & Klyne Internet draft [Page 24]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
11. AUTHORS' ADDRESSES
Derek Atkins
Telcordia Technologies
6 Farragut Ave
Somerville, MA 02144
USA
Telephone: +1 617 623 3745
E-mail: warlord@research.telcordia.com
E-mail: warlord@alum.mit.edu
Graham Klyne
Baltimore Technologies - Content Security Group,
1220 Parkview,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom.
Telephone: +44 118 930 1300
Facsimile: +44 118 930 1301
E-mail: GK@ACM.ORG
Appendix A: Amendment history
00a 01-Feb-2001 Memo initially created.
00b 06-Feb-2001 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.
00c 07-Feb-2001 Folded in some review comments. Fix up some
syntax problems. Other small editorial changes.
Add some references.
TODO:
o confirm urn namespace for headers (currently depends on a work-
in-progress).
o Complete IANA considerations
o Finalize references
o Terminology and conventions section
Atkins & Klyne Internet draft [Page 25]
CPIM Message Format 7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>
REVIEW CHECKLIST:
(Points to be checked or considered more widely on or before final
review.)
o The desirability of a completely rigid syntax.
Full copyright statement
Copyright (C) The Internet Society 2001. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is 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.
Atkins & Klyne Internet draft [Page 26]
