[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 3862

IETF impp WG                      Derek Atkins, Telcordia Technologies
Internet draft                    Graham Klyne, Baltimore Technologies
                                                         30 March 2001
                                               Expires: September 2001


         Common Presence and Instant Messaging Message Format
                 <draft-ietf-impp-cpim-msgfmt-01.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".

  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                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>




Table of contents

1. INTRODUCTION.............................................3
  1.1 Motivation ...........................................3
  1.2 Background ...........................................3
  1.3 Goals ................................................4
  1.4 Terminology and conventions ..........................4
2. OVERALL MESSAGE STRUCTURE................................5
  2.1 Message/cpim MIME headers ............................6
  2.2 Message headers ......................................6
  2.3 Character escape mechanism ...........................7
  2.4 Message content ......................................8
3. MESSAGE HEADER SYNTAX....................................9
  3.1 Header names .........................................9
  3.2 Header Value .........................................9
  3.3 Language Tagging .....................................10
  3.4 Namespaces for header name extensibility .............10
  3.5 Mandatory-to-recognize features ......................12
  3.6 Collected message header syntax ......................14
4. HEADER DEFINITIONS.......................................16
  4.1 The 'From' header ....................................17
  4.2 The 'To' header ......................................18
  4.3 The 'cc' header ......................................19
  4.4 The 'DateTime' header ................................19
     4.4.1 ISO 8601 date-and-time format....................20
  4.5 The 'Subject' header .................................21
  4.6 The 'NS' header ......................................21
  4.7 The 'Require' header .................................22
5. EXAMPLES.................................................22
  5.1 An example message/cpim message ......................23
  5.2 An example using MIME multipart/signed ...............23
6. APPLICATION DESIGN CONSIDERATIONS........................24
7. IANA CONSIDERATIONS......................................25
8. INTERNATIONALIZATION CONSIDERATIONS......................25
9. SECURITY CONSIDERATIONS..................................25
10. ACKNOWLEDGEMENTS........................................26
11. REFERENCES..............................................26
12. AUTHORS' ADDRESSES......................................29
Appendix A: Amendment history...............................29
Full copyright statement....................................30













Atkins & Klyne              Internet draft                    [Page 2]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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
  canonical message format that must be used by any CPIM-compliant
  message transfer protocol, and over which signatures are calculated
  for end-to-end security.

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.

  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.





Atkins & Klyne              Internet draft                    [Page 3]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


  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 (a canonical message
     format for signature calculation)

  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

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 RFC 2119 [1].






Atkins & Klyne              Internet draft                    [Page 4]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


       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.

  [[[Editorial comments and questions about outstanding issues are
  provided in triple brackets like this.  These working comments
  should be resolved and removed prior to final publication.]]]


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.

  Thus, the complete message looks something like this:

     m: Content-type: message/cpim
     s:
     h: (message-metadata-headers)
     s:
     e: (encapsulated MIME message-body)

  The end of the message body is defined by the framing mechanism of
  the protocol used.  The tags 'm:', 's:', 'h:', 'e:', and 'x:' are
  not part of the message format and are used here to indicate the
  different parts of the message, thus:

     m:  MIME headers for the overall message
     s:  a blank separator line
     h:  message headers
     e:  encapsulated MIME object containing the message content
     x:  MIME security multipart message wrapper












Atkins & Klyne              Internet draft                    [Page 5]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


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

  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)








Atkins & Klyne              Internet draft                    [Page 6]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


  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  Headers 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 "Requires:" header.

  o  Interpretation (e.g. equivalence) of header values is dependent
     on the particular header definition.  Message processors MUST
     preserve exactly all octets of all headers (both name and value).

  o  Message processors MUST NOT change the order 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 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.
  (The escape mechanism is as 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.)














Atkins & Klyne              Internet draft                    [Page 7]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


  A 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 "\" may be
  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)

  Quote characters that delimit a string value MUST NOT be escaped.

  On input, any unrecognized escape sequence should be treated as an
  instance of the character following the backslash character.

2.4 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 8]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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 header formats MUST also be
  followed (one line, UTF-8 character encoding, no control
  characters, etc.)








Atkins & Klyne              Internet draft                    [Page 9]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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 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' [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 10]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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 11]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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/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.





Atkins & Klyne              Internet draft                   [Page 12]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


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






































Atkins & Klyne              Internet draft                   [Page 13]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


3.6 Collected message header syntax

  The following description of message header syntax uses ABNF, per
  RFC 2234 [17].  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.

     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




















Atkins & Klyne              Internet draft                   [Page 14]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>



     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     = %21 / %23-26 / %2a-2b / %2d / %5e-60 / %7c / %7e
                  / ALPHA / DIGIT

                  ; Any UCS char except CTLs or SEPARATORS:
     TOKENCHAR    = NAMECHAR / "." / UCS-high

     SEPARATORS   = "(" / ")" / "<" / ">" / "@"    ; 28/29/3c/3e/40
                  / "," / ";" / ":" / "\" / <">    ; 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-ffffffff

  To interpret the syntax as defining UTF-8 coded octet sequences,
  use the following productions:

     UCS-no-CTL   = UTF8-no-CTL
     UCS-high     = UTF8-multi
     UTF8-no-CTL  = %x20-7e / UTF8-multi
     UTF8-multi   = %xC0-DF %x80-BF
                  / %xE0-EF %x80-BF %x80-BF
                  / %xF0-F7 %x80-BF %x80-BF %x80-BF
                  / %xF8-FB %x80-BF %x80-BF %x80-BF %x80-BF
                  / %xFC-FD %x80-BF %x80-BF %x80-BF %x80-BF %x80-BF











Atkins & Klyne              Internet draft                   [Page 15]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


4. HEADER DEFINITIONS

  This specification defines a core set of headers that are defined
  and available for use by applications:  the 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)  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 16]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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 17]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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 18]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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 'DateTime' header

  Specifies the date and time a message was sent.

  Header name:   Date

  Namespace URI: <[[[urn:iana:cpim-headers]]]>

  Syntax:

     DateTime-header = "DateTime" ": " date-time

     (where the syntax of 'date-time' is a profile of ISO8601, defined
     in "Date and Time on the Internet" [23])

     [[[See also section 4.4.1 below]]]









Atkins & Klyne              Internet draft                   [Page 19]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


  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
     header is the current time at the sender when the message was
     transmitted, using ISO 8601 date and time format as profiles in
     "Date and Time on the Internet" [23].

  Example:

     Date: 2001-02-01T12:16:49-05:00

4.4.1 ISO 8601 date-and-time format

  [[[This was lifted from [23], and will be remoived when that
  document has been re-issued.]]]

  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 20]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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 ] SP *HEADERCHAR

  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>
     MyAlias.MyHeader: private-extension-data









Atkins & Klyne              Internet draft                   [Page 21]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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 22]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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: Depressed 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 23]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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 this specification must specify:

  o  a default namespace URI for messages created and processed by
     that application

  o  any namespace prefixes 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 24]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.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-8 character encoding throughout, so can
  convey the full UCS-4 (Unicode, ISO/IEC 10646) character
  repertoire.

  Language tagging is provided for message headers using the
  "Language" parameter.

  Message content is any MIME-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.







Atkins & Klyne              Internet draft                   [Page 25]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


  The resulting message must have no 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, [[[....]]]


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








Atkins & Klyne              Internet draft                   [Page 26]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


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

[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] Crocker, D.H., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne,
     G., Rose, M.T., Rosenberg, J., Sparks, R. and H. Sugano,
     "A Common Profile for Instant Messaging (CPIM)",
     draft-thenine-im-common-00 (work in progress),
     August 2000.

[15] Day, M., Aggarwal, S., Mohr, G., and J. Vincent
     "Instant Messaging / Presence Protocol Requirements"
     RFC 2779
     February 2000.








Atkins & Klyne              Internet draft                   [Page 27]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


[16] N. Freed, K. Moore
     "MIME Parameter Value and Encoded Word Extensions: Character
     Sets, Languages, and Continuations"
     RFC 2231
     November 1997.

[17] D. Crocker, P. Overell
     "Augmented BNF for Syntax Specifications: ABNF"
     RFC 2234
     November 1997.

[18] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
     P. Leach, T. Berners-Lee
     "Hypertext Transfer Protocol -- HTTP/1.1"
     RFC 2616
     June 1999.

[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] F. Yergeau
     "UTF-8, a transformation format of ISO 10646"
     RFC 2279
     January 1998.

[22] M. Mealling
     "A URN Namespace for IANA Registered Protocol Elements"
     draft-mealling-iana-urn-00.txt (work in progress)
     November 2000

[23] C. Newman
     "Date and Time on the Internet"
     draft-newman-datetime-01.txt (work in progress)
     January 1997.














Atkins & Klyne              Internet draft                   [Page 28]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


12. 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,
  1310 Waterside,
  Arlington Business Park
  Theale
  Reading, RG7 4SA
  United Kingdom.
  Telephone: +44 118 903 8000
  Facsimile: +44 118 903 9000
  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.

  01a  29-Mar-2001  Incorporate review comments.  State (simply) that
                    this is a canonical end-to-end format for the
                    purpose of signature calculation.  Defined escape
                    mechanism for control characters.  Header name
                    parameters placed after the ":".  Changed name of
                    Date: header to DateTime:.  Revised syntax to
                    separate character-level syntax from UTF-8 octet-
                    level syntax.

  01b  30-Mar-2001  State explicitly that unrecognized header names
                    should be ignored.  Remove text about





Atkins & Klyne              Internet draft                   [Page 29]


CPIM Message Format                                      30 March 2001
<draft-ietf-impp-cpim-msgfmt-01.txt>


                    (non)significance of header order:  simply say
                    that order must be preserved.

  TODO:

  o  confirm urn namespace for headers (currently depends on a work-
     in-progress).

  o  Complete IANA considerations

  o  Remove date/time syntax section when separate document is
     republished

  REVIEW CHECKLIST:

  (Points to be checked or considered more widely on or before final
  review.)

  o  The desirability of a completely rigid syntax.

  o  Escape mechanism details.


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 30]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/