GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3862

Network Working Group G. Klyne Request for Comments: 3862 Nine by Nine Category: Standards Track D. Atkins

                                                      IHTFP Consulting
                                                           August 2004
    Common Presence and Instant Messaging (CPIM): Message Format

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).

Abstract

 This memo defines the MIME content type 'Message/CPIM', a message
 format for protocols that conform to the Common Profile for Instant
 Messaging (CPIM) specification.

Klyne & Atkins Standards Track [Page 1] RFC 3862 CPIM: Message Format August 2004

Table of Contents

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

Klyne & Atkins Standards Track [Page 2] RFC 3862 CPIM: Message Format August 2004

1. Introduction

 This memo defines the MIME content type 'Message/CPIM', a message
 format for protocols that conform to the Common Profile for Instant
 Messaging (CPIM) specification.  This is a common message format for
 CPIM-compliant messaging protocols [26].
 While being prepared for CPIM, this format is quite general and may
 be reused by other applications with similar requirements.
 Application specifications that adopt this as a base format should
 address the questions raised in section 6 of this document.

1.1. Motivation

 The Common Profile for Instant Messaging (CPIM) [26] specification
 defines a number of operations to be supported and criteria to be
 satisfied for interworking between diverse instant messaging
 protocols.  The intent is to allow a variety of different protocols
 interworking through gateways to support cross-protocol messaging
 that meets the requirements of RFC 2779 [20].
 To adequately meet the security requirements of RFC 2779, a common
 message format is needed so that end-to-end signatures and encryption
 may be applied.  This document describes a common canonical message
 format that must be used by any CPIM-compliant message transfer
 protocol, whereby signatures are calculated for end-to-end security.
 The design of this message format is intended to enable security to
 be applied, while itself remaining agnostic about the specific
 security mechanisms that may be appropriate for a given application.
 For CPIM instant messaging and presence, specific security protocols
 are specified by the CPIM instant messaging [26] and CPIM presence
 [27] specifications.
 Also note that the message format described here is not itself a MIME
 data format, although it may be contained within a MIME object, and
 may contain MIME objects.  See section 2 for more details.

1.2. Background

 RFC 2779 requires that an instant message can carry a MIME payload
 [1][2]; thus some level of support for MIME will be a common element
 of any CPIM compliant protocol.  Therefore it seems reasonable that a
 common message format should use a RFC2822/MIME-like syntax [9], as
 protocol implementations must already contain code to parse this.
 Unfortunately, using pure RFC2822/MIME can be problematic:

Klyne & Atkins Standards Track [Page 3] RFC 3862 CPIM: Message Format August 2004

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

1.3. Goals

 This specification aims to satisfy the following goals:
 o  a securable end-to-end format for a message (a canonical message
    format to serve as a basis for signature calculation, rather than
    specified security mechanisms).

Klyne & Atkins Standards Track [Page 4] RFC 3862 CPIM: Message Format August 2004

 o  independence of any specific application
 o  capability of conveying a range of different address types
 o  assumption of an 8-bit clean message-transfer protocol
 o  evolvable:  extensible by multiple parties
 o  a clear separation of message metadata from message content
 o  a simple, regular, easily parsed syntax
 o  a compact, low-overhead format for simple messages

1.4. Terminology and Conventions

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in BCP 14, RFC 2119 [4].
 NOTE: Comments like this provide additional nonessential information
 about the rationale behind this document.  Such information is not
 needed for building a conformant implementation, but may help those
 who wish to understand the design in greater depth.

2. Overall Message Structure

 The CPIM message format encapsulates arbitrary MIME message content,
 together with message- and content-related metadata.  This can
 optionally be signed or encrypted using MIME security multiparts in
 conjunction with an appropriate security scheme.
 A Message/CPIM object is a two-part entity, where the first part
 contains the message metadata and the second part is the message
 content.  The two parts are separated from the enclosing MIME header
 fields and also from each other by blank lines.  The message metadata
 header information obeys more stringent syntax rules than the MIME
 message content headers that may be carried within the message.
 A complete message looks something like this:
    m: Content-type: Message/CPIM
    s:
    h: (message-metadata-headers)
    s:
    e: (encapsulated MIME message-body)

Klyne & Atkins Standards Track [Page 5] RFC 3862 CPIM: Message Format August 2004

 The end of the message body is defined by the framing mechanism of
 the protocol used.  The tags 'm:', 's:', 'h:', 'e:', and 'x:' are not
 part of the message format and are used here to indicate the
 different parts of the message, thus:
    m:  MIME headers for the overall message
    s:  a blank separator line
    h:  message headers
    e:  encapsulated MIME object containing the message content
    x:  MIME security multipart message wrapper

2.1. Message/CPIM MIME Headers

 The message MIME headers identify the message as a CPIM-formatted
 message.
 The only required MIME header is:
    Content-type: Message/CPIM
 Other MIME headers may be used as appropriate for the message
 transfer environment.

2.2. Message Headers

 Message headers carry information relevant to the end-to-end transfer
 of the message from sender to receiver.  Message headers MUST NOT be
 modified, reformatted or reordered in transit, but in some
 circumstances they MAY be examined by a CPIM message transfer
 protocol.
 The message headers serve a similar purpose to RFC 2822 message
 headers in email [9], and have a similar but restricted allowable
 syntax.
 The basic header syntax is:
    Key: Value
 where "Key" is a header name and "Value" is the corresponding header
 value.
 The following considerations apply:
 o  The entire header MUST be contained on a single line.  The line
    terminator is not considered part of the header value.

Klyne & Atkins Standards Track [Page 6] RFC 3862 CPIM: Message Format August 2004

 o  Only one header per line.  Multiple headers MUST NOT be included
    on a single line.
 o  Processors SHOULD NOT impose any line-length limitations.
 o  There MUST NOT be any whitespace at the beginning or end of a
    line.
 o  UTF-8 character encoding [13] MUST be used throughout.
 o  The character sequence CR,LF (13,10) MUST be used to terminate
    each line.
 o  The header name contains only US-ASCII characters (see section 3.1
    and section 3.6 for the specific syntax).
 o  The header MUST NOT contain any control characters (0-31).  If a
    header value needs to represent control characters then the escape
    mechanism described below MUST be used.
 o  There MUST be a single space character (32) following the header
    name and colon.
 o  Multiple headers using the same key (header name) are allowed.
    (Specific header semantics may dictate only one occurrence of any
    particular header.)
 o  Header names MUST match exactly (i.e., "From:" and "from:" are
    different headers).
 o  If a header name is not recognized or not understood, the header
    should be ignored.  But see also the "Require:" header (section
    4.7).
 o  Interpretation (e.g., equivalence) of header values is dependent
    on the particular header definition.  Message processors MUST
    preserve all octets of all headers (both name and value) exactly.
 o  Message processors MUST NOT change the order of message headers.
 Examples:
    To: Pooh Bear <im:pooh@100akerwood.com>
    From: <im:piglet@100akerwood.com>
    DateTime: 2001-02-02T10:48:54-05:00

Klyne & Atkins Standards Track [Page 7] RFC 3862 CPIM: Message Format August 2004

2.3. Character Escape Mechanism

 This mechanism MUST be used to code control characters in a header,
 having Unicode code points in the range U+0000 to U+001f or U+007f.
 (Rather than invent something completely new, the escape mechanism
 has been adopted from that used by the Java programming language.)
 Note that the escape mechanism is applied to a UCS-2 character, NOT
 to the octets of its UTF-8 coding.  Mapping from/to UTF-8 coding is
 performed without regard for escape sequences or character coding.
 (The header syntax is defined so that octets corresponding to control
 characters other than CR and LF do not appear in the output.)
 An arbitrary UCS-2 character is escaped using the form:
    \uxxxx
 where:
    \     is U+005c (backslash)
    u     is U+0075 (lower case letter U)
    xxxx  is a sequence of exactly four hexadecimal digits
          (0-9, a-f or A-F) or
          (U+0030-U+0039, U+0041-U+0046, or U+0061-0066)
 The hexadecimal number 'xxxx' is the UCS code-point value of the
 escaped character.
 Further, the following special sequences introduced by "\" are used:
    \\    for \ (backslash, U+005c)
    \"    for " (double quote, U+0022)
    \'    for ' (single quote, U+0027)
    \b    for backspace (U+0008)
    \t    for tab (U+0009)
    \n    for linefeed (U+000a)
    \r    for carriage return (U+000d)

2.3.1. Escape Mechanism Usage

 When generating messages conformant with this specification:
 o  The special sequences listed above MUST be used to encode any
    occurrence of the following characters that appear anywhere in a
    header: backslash (U+005c), backspace (U+0008), tab (U+0009),
    linefeed (U+000a) or carriage return (U+000d).

Klyne & Atkins Standards Track [Page 8] RFC 3862 CPIM: Message Format August 2004

 o  The special sequence \" MUST be used for any occurrence of a
    double quote (U+0022) that appears within a string delimited by
    double quotes.
 o  The special sequence \' MUST be used for any occurrence of a
    single quote (U+0027) that appears within a string delimited by
    single quotes.
 o  Single- or double-quote characters that delimit a string value
    MUST NOT be escaped.
 o  The general escape sequence \uxxxx MUST be used for any other
    control character (U+0000 to U+0007, U+000b to U+000c, U+000e to
    U+001f or u+007f) that appears anywhere in a header.
 o  All other characters MUST NOT be represented using an escape
    sequence.
 When processing a message based on this specification, the escape
 sequence usage described above MUST be recognized.
 Further, any other occurrence of an escape sequence described above
 SHOULD be recognized and treated as an occurrence of the
 corresponding Unicode character.
 Any backslash ('\') character SHOULD be interpreted as introducing an
 escape sequence.  Any unrecognized escape sequence SHOULD be treated
 as an instance of the character following the backslash character.
 An isolated backslash that is the last character of a header SHOULD
 be ignored.

2.4. Message Content

 The final section of a Message/CPIM is the MIME-encapsulated message
 content, which follows standard MIME formatting rules [1][2].
 The MIME content headers MUST include at least a Content-Type header.
 The content may be any MIME type.
 Example:
    e: Content-Type: text/plain; charset=utf-8
    e: Content-ID: <1234567890@foo.com>
    e:
    e: This is my encapsulated text message content

Klyne & Atkins Standards Track [Page 9] RFC 3862 CPIM: Message Format August 2004

3. Message Header Syntax

 A header contains two parts, a name and a value, separated by a colon
 character (':') and single space (32).  It is terminated by the
 sequence CR,LF (13,10).
 Headers use UTF-8 character encoding throughout, per RFC 3629 [13].
 NOTE: in the descriptions that follow, header field names and other
 specified text values MUST be used exactly as given, using exactly
 the indicated upper- and lower- case letters.  In this respect, the
 ABNF usage differs from RFC 2234 [6].

3.1. Header Names

 The header name is a sequence of US-ASCII characters, excluding
 control, SPACE or separator characters.  Use of the character "." in
 a header name is reserved for a namespace prefix separator.
 Separator characters are:
    SEPARATORS   = "(" / ")" / "<" / ">" / "@"
                 / "," / ";" / ":" / "\" / DQUOTE
                 / "/" / "[" / "]" / "?" / "="
                 / "{" / "}" / SP
 NOTE: The range of allowed characters was determined by examination
 of HTTP and RFC 2822 header name formats and choosing the more
 restricted.  The intent is to allow CPIM headers to follow a syntax
 that is compatible with the allowed syntax for both RFC 2822 [9] and
 HTTP [18] (including HTTP-derived protocols such as SIP [21]).

3.2. Header Value

 A header value has a structure defined by the corresponding header
 specification.  Implementations that use a particular header must
 adhere to the format and usage rules thus defined when creating or
 processing a message containing that header.
 The other general constraints on header formats MUST also be followed
 (one line, UTF-8 character encoding, no control characters, etc.)

3.3. Language tagging

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

Klyne & Atkins Standards Track [Page 10] RFC 3862 CPIM: Message Format August 2004

 A message header may indicate a language for its value by including
 ';lang=tag' after the header name and colon, where 'tag' is a
 language identifying token per RFC 3066 [10].
 Example:
    Subject:;lang=fr Objet de message
 If the language parameter is not applied a header, any human-readable
 text is assumed to use the language identified as 'i-default' [7].

3.4. Namespaces for Header Name Extensibility

 NOTE: This section defines a framework for header extensibility whose
 use is optional.  If no header extensions are allowed by an
 application then these structures may never be used.
 An application that uses this message format is expected to define
 the set of headers that are required and allowed for that
 application.  This section defines a header extensibility framework
 that can be used with any application.
 The extensibility framework is based on that provided for XML [22] by
 XML namespaces [23].  All headers are associated with a "namespace",
 which is in turn associated with a globally unique URI.
 Within a particular message instance, header names are associated
 with a particular namespace through the presence or absence of a
 namespace prefix, which is a leading part of the header name followed
 by a period ("."); e.g.,
    prefix.header-name: header-value
 Here, 'prefix' is the header name prefix, 'header-name' is the header
 name within the namespace associated with 'prefix', and 'header-
 value' is the value for this header.
    header-name: header-value
 In this case, the header name prefix is absent, and the given
 'header-name' is associated with a default namespace.
 The Message/CPIM media type registration designates a default
 namespace for any headers that are not more explicitly associated
 with any namespace.  In most cases, this default namespace is all
 that is needed.

Klyne & Atkins Standards Track [Page 11] RFC 3862 CPIM: Message Format August 2004

 A namespace is identified by a URI.  In this usage, the URI is used
 simply as a globally unique identifier, and there is no requirement
 that it can be used for any other purpose.  Any legal globally unique
 URI MAY be used to identify a namespace.  (By "globally unique", we
 mean constructed according to some set of rules so that it is
 reasonable to expect that nobody else will use the same URI for a
 different purpose.)  A URI used as an identifier MUST be a full
 absolute-URI, per RFC 2396 [8].  (Relative URIs and URI-references
 containing fragment identifiers MUST NOT be used for this purpose.)
 Within a specific message, an 'NS' header is used to declare a
 namespace prefix and associate it with a URI that identifies a
 namespace.  Following that declaration, within the scope of that
 message, the combination of namespace prefix and header name
 indicates a globally unique identifier for the header (consisting of
 the namespace URI and header name).
 For example:
    NS: MyFeatures <mid:MessageFeatures@id.foo.com>
    MyFeatures.WackyMessageOption: Use-silly-font
 This defines a namespace prefix 'MyFeatures' associated with the
 namespace identifier 'mid:MessageFeatures@id.foo.com'.  Subsequently,
 the prefix indicates that the WackyMessageOption header name
 referenced is associated with the identified namespace.
 A namespace prefix declaration MUST precede any use of that prefix.
 With the exception of any application-specific predefined namespace
 prefixes (see section 6), a namespace prefix is strictly local to the
 message in which it occurs.  The actual prefix used has no global
 significance.  This means that the headers:
    xxx.name: value
    yyy.name: value
 in two different messages may have exactly the same effect if
 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

Klyne & Atkins Standards Track [Page 12] RFC 3862 CPIM: Message Format August 2004

 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.

Klyne & Atkins Standards Track [Page 13] RFC 3862 CPIM: Message Format August 2004

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

Klyne & Atkins Standards Track [Page 14] RFC 3862 CPIM: Message Format August 2004

              ; 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].

Klyne & Atkins Standards Track [Page 15] RFC 3862 CPIM: Message Format August 2004

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.

Klyne & Atkins Standards Track [Page 16] RFC 3862 CPIM: Message Format August 2004

    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>

Klyne & Atkins Standards Track [Page 17] RFC 3862 CPIM: Message Format August 2004

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

Klyne & Atkins Standards Track [Page 18] RFC 3862 CPIM: Message Format August 2004

    (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

Klyne & Atkins Standards Track [Page 19] RFC 3862 CPIM: Message Format August 2004

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.

Klyne & Atkins Standards Track [Page 20] RFC 3862 CPIM: Message Format August 2004

    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>

Klyne & Atkins Standards Track [Page 21] RFC 3862 CPIM: Message Format August 2004

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.

Klyne & Atkins Standards Track [Page 22] RFC 3862 CPIM: Message Format August 2004

 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.

Klyne & Atkins Standards Track [Page 23] RFC 3862 CPIM: Message Format August 2004

 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

Klyne & Atkins Standards Track [Page 24] RFC 3862 CPIM: Message Format August 2004

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

Klyne & Atkins Standards Track [Page 25] RFC 3862 CPIM: Message Format August 2004

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
      Extensions (MIME) Part Two: Media Types", RFC 2046, November
      1996.

Klyne & Atkins Standards Track [Page 26] RFC 3862 CPIM: Message Format August 2004

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

11.2. Informative References

 [14] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
      Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
      RFC 1847, October 1995.
 [15] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson,
      R., Crispin, M., and P. Svanberg, "The Report of the IAB
      Character Set Workshop held 29 February - 1 March, 1996", RFC
      2130, April 1997.
 [16] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
      Extensions: Character Sets, Languages, and Continuations", RFC
      2231, November 1997.

Klyne & Atkins Standards Track [Page 27] RFC 3862 CPIM: Message Format August 2004

 [17] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP
      Message Format", RFC 2440, November 1998.
 [18] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
      Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
      HTTP/1.1", RFC 2616, June 1999.
 [19] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
      2633, June 1999.
 [20] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
      Messaging / Presence Protocol Requirements", RFC 2779, February
      2000.
 [21] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
      Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
      Session Initiation Protocol", RFC 3261, June 2002.
 [22] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
      "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
      Recommendation xml, October 2000,
      <http://www.w3.org/TR/2000/REC-xml-20001006>.
 [23] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C
      Recommendation xml-names, January 1999,
      <http://www.w3.org/TR/REC-xml-names>.
 [24] International Organization for Standardization, "Data elements
      and interchange formats - Information interchange -
      Representation of dates and times", ISO Standard 8601, June
      1988.
 [25] International Organization for Standardization, "Information
      Technology - Universal Multiple-octet coded Character Set (UCS)
      - Part 1: Architecture and Basic Multilingual Plane", ISO
      Standard 10646-1, May 1993.
 [26] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC
      3860, August 2004.
 [27] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
      August 2004.
 [28] Bellovin, S., Kaufman, C., and J. Schiller, "Security Mechanisms
      for the Internet", RFC 3631, December 2003.
 [29] Rescorla, E., "A Survey of Authentication Mechanisms", Work in
      Progress, March 2004.

Klyne & Atkins Standards Track [Page 28] RFC 3862 CPIM: Message Format August 2004

 [30] The Unicode Consortium, "The Unicode Standard, Version 4.0",
      Addison-Wesley, Boston, MA. ISBN 0-321-18578-1, April 2003,
      <http://www.unicode.org/unicode/standard/versions/
      enumeratedversions.html#Unicode_4_0_0>.

12. Authors' Addresses

 Graham Klyne
 Nine by Nine
 EMail: GK-IETF@ninebynine.org
 URI:   http://www.ninebynine.net/
 Derek Atkins
 IHTFP Consulting
 6 Farragut Ave
 Somerville, MA  02144
 USA
 Phone: +1 617 623 3745
 EMail: derek@ihtfp.com, warlord@alum.mit.edu

Klyne & Atkins Standards Track [Page 29] RFC 3862 CPIM: Message Format August 2004

13. Full Copyright Statement

 Copyright (C) The Internet Society (2004).  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 assignees.
 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Klyne & Atkins Standards Track [Page 30]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3862.txt · Last modified: 2004/08/16 19:32 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki