IETF impp WG                      Derek Atkins, Telcordia Technologies
Internet draft                    Graham Klyne, Baltimore Technologies
                                                       7 February 2001
                                                  Expires: August 2001


         Common Presence and Instant Messaging Message Format
                 <draft-ietf-impp-cpim-msgfmt-00.txt>

Status of this memo

  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC 2026.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that
  other groups may also distribute working documents as Internet-
  Drafts.

  Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other
  documents at any time.  It is inappropriate to use Internet-Drafts
  as reference material or to cite them other than as "work in
  progress".

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.



  To view the entire list of current Internet-Drafts, please check
  the "1id-abstracts.txt" listing contained in the Internet-Drafts
  Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
  (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
  West Coast).

Copyright Notice

  Copyright (C) The Internet Society 2001.  All Rights Reserved.

Abstract

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

Discussion of this document

  Please send comments to:  <impp@iastate.edu>.

  To subscribe:  send a message with the body 'subscribe' to <impp-
  request@iastate.edu>.  The mailing list archive is at
  <http://www.imppwg.org>.






Atkins & Klyne              Internet draft                    [Page 1]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>




Table of contents

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















Atkins & Klyne              Internet draft                    [Page 2]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>




1. INTRODUCTION

  This memo defines the mime content-type 'message/cpim.  This is a
  common message format for CPIM-compliant instant messaging
  protocols [14].

  While being prepared for CPIM, this format is quite general and may
  be reused by other applications with similar requirements.

1.1 Motivation

  The Common Profile for Instant Messaging (CPIM) [14] specification
  defines a number of operations to be supported and criteria to be
  satisfied for interworking diverse instant messaging protocols.
  The intent is to allow a veriety of different protocols
  interworking through gateways to support cross-protocol messaging
  that meets the requirements of RFC 2779 [15].

  To adequately meet the security requirements of RFC 2779, a common
  message format is needed so that end-to-end signatures and
  encryption may be applied.  This document describes a common
  message format that must be used by any CPIM-compliant message
  transfer protocol.

  Also, because CPIM is a set of functional requirements, not a
  specific protocol, some different format may be used when actually
  sending a message;  in such cases, the format defined here defines
  a basis for computing hash values for passing digital signatures
  between different CPIM-compliant protocols.

1.2 Background

  RFC 2779 requires that an instant message can carry a MIME payload
  [3,4];  thus some level of support for MIME will be a common
  element of any CPIM compliant protocol.  Therefore it seems
  reasonable that a common message format should use a MIME/RFC822
  syntax, as protocol implementations must already contain code to
  parse this.

  Unfortunately, using pure RFC822/MIME [2] can be problematic:

  o  Irregular lexical structure -- RFC822 allows a number of optional
     encodings and multiple ways to encode a particular value.  For
     example RFC822 comments may be encoded in multiple ways.  For
     security purposes, a single encoding method must be defined as a
     basis for computing message digest values.  Protocols that
     transmit data in a different format would otherwise lose
     information needed to verify a signature.





Atkins & Klyne              Internet draft                    [Page 3]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


  o  Weak internationalization -- RFC822 requires header values to use
     7-bit ASCII, which is problematic for encoding international
     character sets.  Mechanisms for language tagging in RFC822
     headers [16] are awkward to use and have limited applicability.

  o  Mutability -- addition, modification or removal of header
     information.  Because it is not explicitly forbidden, many
     applications that process MIME content (e.g. MIME gateways)
     rebuild or restructure messages in transit.  This obliterates
     most attempt at achieving security (e.g. signatures), leaving
     receiving applications unable to verify the received data.

  o  Message and payload separation -- there is not a clear syntactic
     distinction between message metadata and message content.

  o  Limited extensibility (X-headers are problematic).

  o  No support for structured information (text string values only).

  o  Some processors impose line length limitations

  The message format defined by this memo overcomes some of these
  difficulties by having a syntax that is generally compatible with
  the format accepted by MIME/RFC822 parsers, but simplified, and
  having a stricter syntax.  It also defines mechanisms to support
  some desired features not covered by the RFC822/MIME format
  specifications.

1.3 Goals

  This specification aims to satisfy the following goals:

  o  a securable end-to-end format for a message

  o  independent of any specific application

  o  capable of conveying a range of different address types

  o  assumes an 8-bit clean message-transfer protocol

  o  evolvable: extensible by multiple parties

  o  to clearly separate message metadata from message content

  o  a simple, regular, easily parsed syntax

  o  a compact, low-overhead format for simple messages

  [[[Some message transfer protocols may choose (unwisely) to use
  their own proprietary formats on-the-wire.  A goal of the





Atkins & Klyne              Internet draft                    [Page 4]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


  message/cpim format is to enable such protocols to generate a
  canonical format on-the-fly for security or transfer to another
  protocol.]]]

  [[[A very strict syntax is necessary to limit the amount of extra
  data that message tranfer protocols need to re-create a
  message/cpim message (e.g. for signature verification).  If
  multiple spaces are allowed, then a transfer protocol would need to
  keep the context for the number of spaces used between the key and
  value.]]]

1.4 Terminology and conventions

  [[[Standard stuff about RFC 2119]]]


2. OVERALL MESSAGE STRUCTURE

  The message/cpim format encapsulates an arbitrary MIME message
  content, together with message- and content-related metadata.  This
  can optionally be signed or encrypted using MIME security
  multiparts in conjunction with an appropriate security scheme.

  A message/cpim object is a multipart entity, where the first part
  contains the message metadata and the second part is the message
  content.  The two parts are syntactically separated by a blank
  line, to keep the message header information (with its more
  stringent syntax rules) separate from the MIME message content
  headers.

  The message/cpim format is a MIME object containing two parts:
  message headers (metadata) and message content, separated by a
  blank line.

  Thus, the complete message looks something like this:

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














Atkins & Klyne              Internet draft                    [Page 5]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


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

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

2.1 Message/cpim MIME headers

  The message MIME headers identify the message as a CPIM-formatted
  message.  The only required header is:

     Content-type: message/cpim

  Other MIME headers may be used as appropriate for the message
  transfer environment.

2.2 Message headers

  Message headers carry information relevant to the end-to-end
  transfer of the message of the message from sender to receiver.
  Message headers MUST NOT be modified or reformatted in transit, but
  in some circumstances they MAY be examined by a CPIM message
  transfer protocol.

  The message headers serve a similar purpose to RFC822 message
  headers in email [2], and have a similar but restricted allowable
  syntax.

  The basic header syntax is:

     Key: Value

  where "Key" is a header name and "Value" is the corresponding
  header value.  The following considerations apply:

  o  The entire header MUST be contained on a single line.  The line
     terminator is not considered part of the header value.

  o  Only one header per line.  Multiple headers MUST NOT be included
     on a single line.

  o  Processors SHOULD NOT impose any line-length limitations.

  o  There MUST NOT be any whitespace at the beginning or end of a
     line.





Atkins & Klyne              Internet draft                    [Page 6]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


  o  UTF-8 character encoding [21] MUST be used throughout.

  o  The character sequence CR,LF (13,10) MUST be used to terminate
     each line.

  o  The header name contains only US-ASCII characters (see later for
     the specific syntax)

  o  The header MUST NOT contain any control characters (0-31).  If a
     header value needs to represent control characters then a
     suitable escape mechanism must be defined.

     [[[???define a standard escape mechanism???  If so, what about
     URIs, and other objects with their own defined mechanisms???]]]

  o  There MUST be a single space character (32) following the header
     name and colon.

  o  Multiple headers using the same key (header name) are allowed.
     (Specific header semantics may dictate only one occurrence of any
     particular header.)

  o  Headers names are case-sensitive.

  o  Case-sensitivity of the header values are dependent on the
     particular header definition.  Message processors MUST preserve
     the case of all headers (both the header name and header value).

  o  The order of headers is not generally significant, except
     possibly where there are multiple occurrences of a given header
     name.  Message processors MUST preserve the ordering of message
     headers.

  Examples:

     To: Pooh Bear <im:pooh@100akerwood.com>
     From: <im:piglet@100akerwood.com>
     Date: 2001-02-02T10:48:54-05:00

2.3 Message content

  The final section of a message/cpim is the MIME-encapsulated
  message content, which follows standard MIME formatting rules
  [3,4].

  The MIME content headers MUST include at least a Content-Type
  header.  The content may be any MIME type.








Atkins & Klyne              Internet draft                    [Page 7]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


  Example:

     Content-Type: text/plain; charset=utf-8
     Content-ID: <1234567890@foo.com>

     This is my encapsulated text message content


3. MESSAGE HEADER SYNTAX

  A header is made of two parts, a name and a value, separated by a
  colon character (':') followed by a single space (32), and
  terminated by a sequence of CR,LF (13,10).

  Headers use UTF-8 character encoding thoughout, per RFC 2279 [21].

3.1 Header names

  The header name is a sequence of US-ASCII characters, excluding
  control characters, SPACE or separator characters.  Use of the
  character "." in a header name is reserved for a namespace prefix
  separator.

  Separator characters are:

     SEPARATORS   = "(" / ")" / "<" / ">" / "@"
                  / "," / ";" / ":" / "\" / <">
                  / "/" / "[" / "]" / "?" / "="
                  / "{" / "}" / SP

       NOTE:  the range of allowed characters was determined by
       examination of HTTP and RFC822 header name formats and
       choosing the more resticted.  The intent is to allow CPIM
       headers to follow a syntax that is compatible with the
       allowed syntax for both RFC 822 [2] and HTTP [18]
       (including HTTP-derived protocols such as SIP).

3.2 Header Value

  A header value has a structure defined by the corresponding header
  specification.  Implementations that use a particular header must
  adhere to the format and usage rules thus defined when creating or
  processing a message containing that header.

  The other general constraints on hjeader formats MUST also be
  followed (one line, UTF-8 character encoding, no control
  characters, etc.)








Atkins & Klyne              Internet draft                    [Page 8]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


3.3 Language Tagging

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

  A message header may indicate a language for the associated value
  by including a language parameter ';lang=tag' after the header name
  and preceding the colon, where 'tag' is a language identifying
  token per RFC 3066 [7].

  Example:

     Subject;lang=fr: Subjet de message

  If the language parameter is not applied a header, any human-
  readable text is assumed to use the language identified as
  'i-default' [19].

3.4 Namespaces for header name extensibility

       NOTE: this section defines a framework for header
       extensibility whose use is optional.  If no header
       extensions are allowed by an application then these
       structures may never be used.

  An application that uses this message format is expected to define
  the set of headers that are required and allowed for that
  application.  This section defines a header extensibility framework
  that can be used with any application.

  The extensibility framework is based on that provided for XML [11]
  by XML namespaces [12].  All headers are associated with a
  "namespace", which is in turn associated with a globally unique
  URI.  Within a particular message instance, header names are
  associated with a particular namespace through the presence or
  absence of a namespace prefix, which is a leading part of the
  header name followed by a period ("."); e.g.

     prefix.header-name: header-value

  Here, 'prefix' is the header name prefix, 'header-name' is the
  header name within the namespace associated with 'prefix', and
  'header-value' is the value for this header.

     header-name: header-value

  In this case, the header name prefix is absent, and the given
  'header-name' is associated with a default namespace.







Atkins & Klyne              Internet draft                    [Page 9]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


  An application that uses this format designates a default namespace
  for any headers that are not more explicitly associated with any
  namespace.  In many cases, the default namespace may be all that is
  needed.

  A namespace is identified by a URI.  In this usage, the URI is used
  simply as a globally unique identifier, and there is no requirement
  that it can be used for any other purpose.  Any legal globally
  unique URI MAY be used to identify a namespace (by "globally
  unique", we mean constructed according to some set of rules so that
  it is reasonable to expect that nobody else will use the same URI
  for a different purpose).  A URI used as an identifier MUST be a
  full absolute-URI, per RFC 2396 [10].  (Relative URIs and URI-
  references containing fragment identifiers MUST NOT be used for
  this purpose.)

  Within a specific message, a 'NS' header is used to declare a
  namespace prefix and associate it with a URI that identifies a
  namespace.  Following that declaration, within the scope of that
  message, the combination of namespace prefix and header name
  indicates a globally unique identifier for the header (consisting
  of the namespace URI and header name).  For example:

     NS: MyFeatures <mid:MessageFeatures@id.foo.com>
     MyFeatures.WackyMessageOption: Use-silly-font

  This defines a namespace prefix 'MyFeatures' associated with the
  namespace identifier 'mid:MessageFeatures@id.foo.com'.
  Subsequently the prefix indicates that the WackyMessageOption
  header name referenced is associated with the identified namespace.

  A namespace prefix declaration MUST precede any use of that prefix.























Atkins & Klyne              Internet draft                   [Page 10]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


  With the exception of any application-specific predefined namespace
  prefixes (see section 6), a namespace prefix is strictly local to
  the message in which it occurs.  The actual prefix used has no
  global significance.  Thus, the headers:

     xxx.name: value

     yyy.name: value

  in two different messages may have exactly the same effect if
  namespace prefixes 'xxx' and 'yyy' are associated with the same
  namespace URI.  Thus the following have exactly the same meaning:

     NS: acme <http://id.acme.widgets/wily-headers/>
     acme.runner-trap: set

  and

     NS: widget <http://id.acme.widgets/wiley-headers/>
     widget.runner-trap: set

  A 'NS' header without a header prefix name specifies a default
  namespace for subsequent headers;  that is a namespace that is
  associated with header names not having a prefix.  For example:

     NS: <http://id.acme.widgets/wiley-headers/>
     runner-trap: set

  has the same meaning as the previous examples.

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

3.5 Mandatory-to-recognize features

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

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

     Require: MyFeatures.VitalMessageOption
     MyFeatures.VitalMessageOption: Confirmation-requested

  Multiple required header names may be listed in a single 'Require'
  header, separated by commas.





Atkins & Klyne              Internet draft                   [Page 11]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


  Note that indiscriminate use of required headers could harm
  interoperability.  It is suggested that any implementator who
  defines required headers also publish the header specifications so
  other implementations can succesfully interoperate.

  The 'Require' header MAY also be used to indicate that some non-
  header semantics must be implemented by the recipient, even when it
  does not appear as a header.  For example:

     Require: Locale.MustRenderKanji

  might be used to indicate that message content includes characters
  from the Kanji repertoire, which must be rendered for proper
  understanding of the message.  In this case, the header name is
  just a token (using header name syntax and namespace association)
  that indicates some desired behaviour.

3.6 Collected message header syntax

  The following description of message header syntax uses ABNF, per
  RFC 2234 [17].

     Header       = Header-name *( ";" Parameter ) ": "
                    Header-value
                    CRLF

     Header-name  = [ Name-prefix "." ] Name
     Name-prefix  = Token
     Name         = Token

     Parameter    = Lang-param / Ext-param
     Lang-param   = "lang=" Language-tag
     Ext-param    = Param-name "=" Param-value
     Param-name   = Name
     Param-value  = Token / Number / String

     Header-value = *UTF8-no-CTL

     Token        = 1*TOKENCHAR
     Number       = 1*DIGIT
     String       = DQUOTE *( Str-char / Esc-pair ) DQUOTE
     Str-char     = ( %x20-21 / %x23-5B / %x5D-7E / UTF8-multi )
     Esc-pair     = "\" UTF8-no-CTL












Atkins & Klyne              Internet draft                   [Page 12]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>



     Formal-name  = 1*( Token SP ) / String
     URI          = <defined as absolute-URI by RFC 2396>
     Language-tag = <defined by RFC 3066>
     TOKENCHAR    = <Any character except CTLs or SEPARATORS or ".">
     SEPARATORS   = "(" / ")" / "<" / ">" / "@"
                  / "," / ";" / ":" / "\" / <">
                  / "/" / "[" / "]" / "?" / "="
                  / "{" / "}" / SP
     CTL          = <Defined by RFC 2234 -- %x0-%x17, %x7f>
     CRLF         = <Defined by RFC 2234 -- CR, LF>
     SP           = <defined by RFC 2234 -- %x20>
     DIGIT        = <defined by RFC 2234 -- '0'-'9'>
     DQUOTE       = <defined by RFC 2234 -- %x22>
     UTF8-no-CTL  = %x20-7e / UTF8-multi
     UTF8-multi   = %xC0-DF %x80-BF
                  / %xE0-EF %x80-BF %x80-BF
                  / %xF0-F7 %x80-BF %x80-BF %x80-BF
                  / %xF8-FB %x80-BF %x80-BF %x80-BF %x80-BF
                  / %xFC-FD %x80-BF %x80-BF %x80-BF %x80-BF %x80-BF


4. HEADER DEFINITIONS

  This specification defines a core set of headers that may be used
  by CPIM applications:  the application specification must indicate
  the headers that may be used, those that must be recognized and
  those that must be appear in any message.

  [[[This means that the CPIM core specification must list the
  headers that are needed and allowed for CPIM]]]

  The header definitions that follow fall into two categories:

  (a)  those that are part of the CPIM format extensibility
       framework, with header name prefix CPIM.

  (b)  some that have been based on similar headers in RFC 822,
       specified here with corresponding semantics.

  Header names and syntax are given without a namespace
  qualification, and the associated namespace URI is listed as part
  of the header description.  Any of the namespace associations
  already mentioned (implied default namespace, explicit default
  namespace or implied namespace prefix or explicit namespace prefix
  declaration) may be used to identify the namespace.

  All headers defined here are associated with the namespace URI
  <[[[urn:iana:cpim-headers]]]>, which is defined according to [22].






Atkins & Klyne              Internet draft                   [Page 13]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


4.1 The 'From' header

  Indicates the sender of a message.

  Header name:   From

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

  Syntax: (see also section 3.6)

     From-header = "From" ": " [ Formal-name ] "<" URI ">"

  Description:

     Indicates the sender or originator of a message.

     The 'Formal-name' identifies the person or "real world" name for
     the originator.

     The URI indicates an address for the originator.

  Examples:

     From: Winnie the Pooh <im:pooh@100akerwood.com>

     From: <im:tigger@100akerwood.com>





























Atkins & Klyne              Internet draft                   [Page 14]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


4.2 The 'To' header

  Specifies an intended recipient of a message.

  Header name:   To

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

  Syntax: (see also section 3.6)

     To-header = "To" ": " [ Formal-name ] "<" URI ">"

  Description:

     Indicates the recipient of a message.

     The 'Formal-name' identifies the person or "real world" name for
     the recipient.

     The URI indicates an address for the recipient.

     Multiple recipients may be indicated by including multiple 'To'
     headers.

  Examples:

     To: Winnie the Pooh <im:pooh@100akerwood.com>

     To: <im:tigger@100akerwood.com>


























Atkins & Klyne              Internet draft                   [Page 15]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


4.3 The 'cc' header

  Specifies a non-primary recipient ("courtesy copy") for a message.

  Header name:   cc

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

  Syntax: (see also section 3.6)

     Cc-header   = "cc" ": " [ Formal-name ] "<" URI ">"

  Description:

     Indicates a courtesy copy recipient of a message.

     The 'Formal-name', if present, identifies the person or "real
     world" name for the recipient.

     The URI indicates an address for the recipient.

     Multiple courtesy copy recipients may be indicated by including
     multiple 'cc' headers.

  Examples:

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

     cc: <im:tigger@100akerwood.com>

4.4 The 'Date' header

  Specifies the date and time a message was sent.

  Header name:   Date

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

  Syntax: (see also section 8.4.1 below)

     Date-header = "Date" ": " date-time

  Description:

     The 'Date' header supplies the current date and time at which the
     sender sent the message.

     One purpose of the this header is to provide for protection
     against a replay attack, by allowing the recipient to know when
     the message was intended to be sent.  The value of the date





Atkins & Klyne              Internet draft                   [Page 16]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


     header is the current time at the sender when the message was
     transmitted, using ISO 8601 date and time format as defined in
     section 8.4.1 below.

  Example:

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

4.4.1 ISO 8601 date-and-time format

  [[[Suggest RFC-publishing and citing Chris Newman's time-and-date
  draft, from where this was lifted.]]]

  The following profiles ISO 8601 [13] dates, using ABNF [17]:

     date-fullyear   = 4DIGIT
     date-month      = 2DIGIT  ; 01-12
     date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30 or 01-31
     time-hour       = 2DIGIT  ; 00-23
     time-minute     = 2DIGIT  ; 00-59
     time-second     = 2DIGIT  ; 00-59 or 00-60
     time-secfrac    = "." 1*DIGIT
     time-numoffset  = ("+" / "-") time-hour ":" time-minute
     time-offset     = "Z" / time-numoffset

     partial-time    = time-hour ":" time-minute ":" time-second
                       [time-secfrac]
     full-date       = date-fullyear "-" date-month "-" date-mday
     full-time       = partial-time time-offset
     date-time       = full-date "T" full-time

























Atkins & Klyne              Internet draft                   [Page 17]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


4.5 The 'Subject' header

  Contains a description of the topic of the message.

  Header name:   Subject

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

  Syntax: (see also section 3.6)

     Subject-header = "Subject" [ lang-param ] ": " *UTF8-no-CTL

  Description:

     The 'Subject' header supplies the sender's description of the
     topic or content of the message.

     The sending agent should specify the language parameter if it has
     any reasonable knowledge of the language used by the sender to
     describe the message.

  Example:

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

4.6 The 'NS' header

  The "NS" header is used to declare a local namespace prefix.

  Header name:   NS

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

  Syntax: (see also section 3.6)

     NS-header = "NS" ": " [ Name-prefix ] "<" URI ">"

  Description:

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

  Example:

     NS: MyAlias <mid:MessageFeatures@id.foo.com>










Atkins & Klyne              Internet draft                   [Page 18]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


4.7 The 'Require' header

  Specify a header or feature that must be implemented by the
  receiver for correct message processing.

  Header name:   NS

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

  Syntax: (see also section 3.6)

     Require-header = "Require" ": " Header-name *( "," Header-name )

  Description:

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

     Note that there is no requirement that the required header
     actually be used, but for brevity it is recommended that an
     implemention not use issue require header for unused headers.

  Example:

     Require: MyAlias.VitalHeader


5. EXAMPLES

  The examples in the following sections use the following per-line
  tags to indicate different parts of the overall message format:

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

  The following examples also assume that <[[[urn:iana:cpim-
  headers]]]> is the implied default namespace for the application
  concerned.














Atkins & Klyne              Internet draft                   [Page 19]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


5.1 An example message/cpim message

  The following example shows a message/cpim message:

     m: Content-type: message/cpim
     s:
     h: From: MR SANDERS <im:piglet@100akerwood.com>
     h: To: Dopey Donkey <im:eeyore@100akerwood.com>
     h: Date: 2000-12-13T13:40:00-08:00
     h: Subject: Message subject
     h: Subject;lang=fr: Subjet de message
     h: NS: MyFeatures <mid:MessageFeatures@id.foo.com>
     h: Require: MyFeatures.VitalMessageOption
     h: MyFeatures.VitalMessageOption: Confirmation-requested
     h: MyFeatures.WackyMessageOption: Use-silly-font
     s:
     e: Content-type: text/xml; charset=utf-8
     e: Content-ID: <1234567890@foo.com>
     e:
     e: <body>
     e: Here is the text of my message.
     e: </body>

5.2 An example using MIME multipart/signed

  In order to secure a message/cpim, an application or implementation
  should use RFC 1847 and some appropriate cryptographic scheme.




























Atkins & Klyne              Internet draft                   [Page 20]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


  Using S/MIME and pkcs7, the above message would look like this:

     x: Content-Type: multipart/signed; boundary=next;
                      MDALG=SHA-1; type=application/pkcs
     x:
     x: --next
     m: Content-Type: message/cpim
     s:
     h: From: MR SANDERS <im:piglet@100akerwood.com>
     h: To: Dopey Donkey <im:eeyore@100akerwood.com>
     h: Date: 2000-12-13T13:40:00-08:00
     h: Subject: Message subject
     h: Subject;lang=fr: Subjet de message
     h: NS: MyFeatures <mid:MessageFeatures@id.foo.com>
     h: Require: MyFeatures.VitalMessageOption
     h: MyFeatures.VitalMessageOption: Confirmation-requested
     h: MyFeatures.WackyMessageOption: Use-silly-font
     s:
     e: Content-type: text/xml; charset=utf-8
     e: Content-ID: <1234567890@foo.com>
     e:
     e: <body>
     e: Here is the text of my message.
     e: </body>
     x: --next
     x: Content-Type: application/pkcs7
     x:
     x: (signature stuff)
         :
     x: --next--


6. APPLICATION DESIGN CONSIDERATIONS

  Applications using the specification must specify:

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

  o  any namespace prefixes (in addition to CPIM) that are implicitly
     defined for messages created and processed by that application

  o  all headers that must be recognized by implementations of the
     application

  o  any headers that must be present in messages created by that
     application

  Within a network of message transfer agents, an intermediate
  gateway MUST NOT change the message/cpim content in any way.  This





Atkins & Klyne              Internet draft                   [Page 21]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


  implies that headers cannot be changed or reordered, transfer
  encoding cannot be changed, languages cannot be changed, etc.

  Because message/cpim messages are immutable, any transfer agent
  that wants to modify the message should create a new message/cpim
  message with the modified header and containing the original
  message as its content.  (This approach is similar to real-world
  bill-of-lading handling, where each person in the chain attaches a
  new sheet to the message.  Then anyone can validate the original
  message and see what was changed and who changed it by following
  the trail of amendments.  Another metaphor is including the old
  message in a new envelope.)


7. IANA CONSIDERATIONS

  [[[Registration template for message/cpim content type]]]

  [[[Registration of namespace URN for CPIM headers]]]


8. INTERNATIONALIZATION CONSIDERATIONS

  Message headers use UTF character encoding throughout, so can
  convey the full UCS-4 (Unicode) character repertoire.

  Language tagging is provided for message headers.

  Message content is any MIME-ancapsulated content, and normal MIME
  content internationalization considerations apply.


9. SECURITY CONSIDERATIONS

  The message/cpim format is designed with security in mind.  In
  particular it is designed to be used with MIME security multiparts
  for signatures and encryption.  To this end, message/cpim messages
  must be considered immutable once created.

  Because message/cpim messages are binary messages (due to UTF-8
  encoding), if they are transmitted across non-8-bit-clean
  transports then the transfer agent must tunnel the entire message.
  Changing the transfer encoding is not an allowable option.  This
  implies that the message/cpim must be encapsulated by the message
  tranfer system and unencapsulated at the receiving end of the
  tunnel.

  The resulting message must have zero data loss due to the encoding
  and unencoding of the message.  For example, an application may






Atkins & Klyne              Internet draft                   [Page 22]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


  choose to apply the MIME base64 content-transfer-encoding to the
  message/cpim object to meet this requirement.


10. REFERENCES

[1]  Bradner, S.,
     "Key words for use in RFCs to Indicate Requirement Levels",
     RFC 2119,
     March 1997.

[2]  Crocker, D.,
     "Standard for the format of ARPA Internet text messages",
     RFC 822, STD 11,
     August 1982.

[3]  Freed, N. and N. Borenstein,
     "Multipurpose Internet Mail Extensions (MIME) Part One: Format of
     Internet Message Bodies",
     RFC 2045,
     November 1996.

[4]  Freed, N. and N. Borenstein,
     "Multipurpose Internet Mail Extensions (MIME) Part Two: Media
     Types",
     RFC 2046
     November 1996.

[5]  Freed, N., Klensin, J., and J. Postel,
     "Multipurpose Internet Mail Extensions (MIME) Part Four:
     Registration Procedures",
     RFC 2048, BCP 13,
     November 1996.

[6]  Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson,
     R., Crispin, M., Svanberg, P.,
     "Report from the IAB Character Set Workshop",
     RFC 2130,
     April 1997.

[7]  Alvestrand, H.,
     "Tags for the Identification of Languages",
     RFC 3066,
     January 2001.
     (Defines Content-language header.)

[8]  Ramsdell, B.,
     "S/MIME Version 3 Message Specification",
     RFC 2633,
     June 1999.





Atkins & Klyne              Internet draft                   [Page 23]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


[9]  Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
     "OpenPGP Message Format",
     RFC 2440,
     November 1998.

[10] Berners-Lee, T., Fielding, R.T. and L. Masinter,
     "Uniform Resource Identifiers (URI): Generic Syntax",
     RFC 2396,
     August 1998.

[11] Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen,
     "Extensible Markup Language (XML) 1.0",
     W3C recommendation: <http://www.w3.org/TR/REC-xml>,
     10 February 1998.

[12] Tim Bray, Dave Hollander, and Andrew Layman
     "Namespaces in XML",
     W3C recommendation: <http://www.w3.org/TR/REC-xml-names>,
     14 January 1999.

[13] "Data elements and interchange formats _
     Information interchange _ Representation of dates and times"
     ISO 8601:1988(E)
     International Organization for Standardization
     June 1988.

[14] CPIM

[15] RFC 2779: IMPP requirements

[16] RFC 2231: MIME extensions for language tagging

[17] RFC 2234: ABNF

[18] RFC 2616: HTTP/1.1

[19] Alvestrand, H,
     "IETF Policy on Character Sets and Languages",
     RFC 2277, BCP 18,
     January 1998.

[20] Freed, N., and J. Postel,
     "IANA Charset Registration Procedures",
     BCP 19, RFC 2278,
     January 1998.

[21] RFC 2279, UTF-8

[22] IANA URN namespace:  work-in-progress proposal






Atkins & Klyne              Internet draft                   [Page 24]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


11. AUTHORS' ADDRESSES

  Derek Atkins
  Telcordia Technologies
  6 Farragut Ave
  Somerville, MA  02144
  USA
  Telephone: +1 617 623 3745
  E-mail: warlord@research.telcordia.com
  E-mail: warlord@alum.mit.edu

  Graham Klyne
  Baltimore Technologies - Content Security Group,
  1220 Parkview,
  Arlington Business Park
  Theale
  Reading, RG7 4SA
  United Kingdom.
  Telephone: +44 118 930 1300
  Facsimile: +44 118 930 1301
  E-mail:    GK@ACM.ORG


Appendix A: Amendment history

  00a  01-Feb-2001  Memo initially created.

  00b  06-Feb-2001  Editorial review.  Reworked namespace framework
                    description.  Deferred specification of mandatory
                    headers to the application specification, allowing
                    this document to be less application-dependent.
                    Expanded references.  Replaced some text with ABNF
                    syntax descriptions.  Reordered some major
                    sections.

  00c  07-Feb-2001  Folded in some review comments.  Fix up some
                    syntax problems.  Other small editorial changes.
                    Add some references.

  TODO:

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

  o  Complete IANA considerations

  o  Finalize references

  o  Terminology and conventions section






Atkins & Klyne              Internet draft                   [Page 25]
CPIM Message Format                                    7 February 2001
<draft-ietf-impp-cpim-msgfmt-00.txt>


  REVIEW CHECKLIST:

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

  o  The desirability of a completely rigid syntax.


Full copyright statement

  Copyright (C) The Internet Society 2001.  All Rights Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain
  it or assist in its implementation may be prepared, copied,
  published and distributed, in whole or in part, without restriction
  of any kind, provided that the above copyright notice and this
  paragraph are included on all such copies and derivative works.
  However, this document itself may not be modified in any way, such
  as by removing the copyright notice or references to the Internet
  Society or other Internet organizations, except as needed for the
  purpose of developing Internet standards in which case the
  procedures for copyrights defined in the Internet Standards process
  must be followed, or as required to translate it into languages
  other than English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on
  an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
  ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
  IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
  THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




















Atkins & Klyne              Internet draft                   [Page 26]