idnits 2.17.1 draft-ietf-impp-cpim-msgfmt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 26 longer pages, the longest (page 1) being 68 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (7 February 2001) is 8479 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1058, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1066, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1107, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2048 (ref. '5') (Obsoleted by RFC 4288, RFC 4289) ** Downref: Normative reference to an Informational RFC: RFC 2130 (ref. '6') ** Obsolete normative reference: RFC 3066 (ref. '7') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 2633 (ref. '8') (Obsoleted by RFC 3851) ** Obsolete normative reference: RFC 2440 (ref. '9') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2396 (ref. '10') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '15') ** Obsolete normative reference: RFC 2234 (ref. '17') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2616 (ref. '18') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2278 (ref. '20') (Obsoleted by RFC 2978) ** Obsolete normative reference: RFC 2279 (ref. '21') (Obsoleted by RFC 3629) -- Possible downref: Non-RFC (?) normative reference: ref. '22' Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF impp WG Derek Atkins, Telcordia Technologies 3 Internet draft Graham Klyne, Baltimore Technologies 4 7 February 2001 5 Expires: August 2001 7 Common Presence and Instant Messaging Message Format 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please check 33 the "1id-abstracts.txt" listing contained in the Internet-Drafts 34 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 35 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 36 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 37 West Coast). 39 Copyright Notice 41 Copyright (C) The Internet Society 2001. All Rights Reserved. 43 Abstract 45 This memo defines the mime type 'message/cpim', a message format 46 for protocols that conform to the Common Profile for Instant 47 Messaging (CPIM) specification. 49 Discussion of this document 51 Please send comments to: . 53 To subscribe: send a message with the body 'subscribe' to . The mailing list archive is at 55 . 57 CPIM Message Format 7 February 2001 58 60 Table of contents 62 1. INTRODUCTION.............................................3 63 1.1 Motivation ...........................................3 64 1.2 Background ...........................................3 65 1.3 Goals ................................................4 66 1.4 Terminology and conventions ..........................5 67 2. OVERALL MESSAGE STRUCTURE................................5 68 2.1 Message/cpim MIME headers ............................6 69 2.2 Message headers ......................................6 70 2.3 Message content ......................................7 71 3. MESSAGE HEADER SYNTAX....................................8 72 3.1 Header names .........................................8 73 3.2 Header Value .........................................8 74 3.3 Language Tagging .....................................9 75 3.4 Namespaces for header name extensibility .............9 76 3.5 Mandatory-to-recognize features ......................11 77 3.6 Collected message header syntax ......................12 78 4. HEADER DEFINITIONS.......................................13 79 4.1 The 'From' header ....................................14 80 4.2 The 'To' header ......................................15 81 4.3 The 'cc' header ......................................16 82 4.4 The 'Date' header ....................................16 83 4.4.1 ISO 8601 date-and-time format....................17 84 4.5 The 'Subject' header .................................18 85 4.6 The 'NS' header ......................................18 86 4.7 The 'Require' header .................................19 87 5. EXAMPLES.................................................19 88 5.1 An example message/cpim message ......................20 89 5.2 An example using MIME multipart/signed ...............20 90 6. APPLICATION DESIGN CONSIDERATIONS........................21 91 7. IANA CONSIDERATIONS......................................22 92 8. INTERNATIONALIZATION CONSIDERATIONS......................22 93 9. SECURITY CONSIDERATIONS..................................22 94 10. REFERENCES..............................................23 95 11. AUTHORS' ADDRESSES......................................25 96 Appendix A: Amendment history...............................25 97 Full copyright statement....................................26 98 CPIM Message Format 7 February 2001 99 101 1. INTRODUCTION 103 This memo defines the mime content-type 'message/cpim. This is a 104 common message format for CPIM-compliant instant messaging 105 protocols [14]. 107 While being prepared for CPIM, this format is quite general and may 108 be reused by other applications with similar requirements. 110 1.1 Motivation 112 The Common Profile for Instant Messaging (CPIM) [14] specification 113 defines a number of operations to be supported and criteria to be 114 satisfied for interworking diverse instant messaging protocols. 115 The intent is to allow a veriety of different protocols 116 interworking through gateways to support cross-protocol messaging 117 that meets the requirements of RFC 2779 [15]. 119 To adequately meet the security requirements of RFC 2779, a common 120 message format is needed so that end-to-end signatures and 121 encryption may be applied. This document describes a common 122 message format that must be used by any CPIM-compliant message 123 transfer protocol. 125 Also, because CPIM is a set of functional requirements, not a 126 specific protocol, some different format may be used when actually 127 sending a message; in such cases, the format defined here defines 128 a basis for computing hash values for passing digital signatures 129 between different CPIM-compliant protocols. 131 1.2 Background 133 RFC 2779 requires that an instant message can carry a MIME payload 134 [3,4]; thus some level of support for MIME will be a common 135 element of any CPIM compliant protocol. Therefore it seems 136 reasonable that a common message format should use a MIME/RFC822 137 syntax, as protocol implementations must already contain code to 138 parse this. 140 Unfortunately, using pure RFC822/MIME [2] can be problematic: 142 o Irregular lexical structure -- RFC822 allows a number of optional 143 encodings and multiple ways to encode a particular value. For 144 example RFC822 comments may be encoded in multiple ways. For 145 security purposes, a single encoding method must be defined as a 146 basis for computing message digest values. Protocols that 147 transmit data in a different format would otherwise lose 148 information needed to verify a signature. 150 CPIM Message Format 7 February 2001 151 153 o Weak internationalization -- RFC822 requires header values to use 154 7-bit ASCII, which is problematic for encoding international 155 character sets. Mechanisms for language tagging in RFC822 156 headers [16] are awkward to use and have limited applicability. 158 o Mutability -- addition, modification or removal of header 159 information. Because it is not explicitly forbidden, many 160 applications that process MIME content (e.g. MIME gateways) 161 rebuild or restructure messages in transit. This obliterates 162 most attempt at achieving security (e.g. signatures), leaving 163 receiving applications unable to verify the received data. 165 o Message and payload separation -- there is not a clear syntactic 166 distinction between message metadata and message content. 168 o Limited extensibility (X-headers are problematic). 170 o No support for structured information (text string values only). 172 o Some processors impose line length limitations 174 The message format defined by this memo overcomes some of these 175 difficulties by having a syntax that is generally compatible with 176 the format accepted by MIME/RFC822 parsers, but simplified, and 177 having a stricter syntax. It also defines mechanisms to support 178 some desired features not covered by the RFC822/MIME format 179 specifications. 181 1.3 Goals 183 This specification aims to satisfy the following goals: 185 o a securable end-to-end format for a message 187 o independent of any specific application 189 o capable of conveying a range of different address types 191 o assumes an 8-bit clean message-transfer protocol 193 o evolvable: extensible by multiple parties 195 o to clearly separate message metadata from message content 197 o a simple, regular, easily parsed syntax 199 o a compact, low-overhead format for simple messages 201 [[[Some message transfer protocols may choose (unwisely) to use 202 their own proprietary formats on-the-wire. A goal of the 203 CPIM Message Format 7 February 2001 204 206 message/cpim format is to enable such protocols to generate a 207 canonical format on-the-fly for security or transfer to another 208 protocol.]]] 210 [[[A very strict syntax is necessary to limit the amount of extra 211 data that message tranfer protocols need to re-create a 212 message/cpim message (e.g. for signature verification). If 213 multiple spaces are allowed, then a transfer protocol would need to 214 keep the context for the number of spaces used between the key and 215 value.]]] 217 1.4 Terminology and conventions 219 [[[Standard stuff about RFC 2119]]] 221 2. OVERALL MESSAGE STRUCTURE 223 The message/cpim format encapsulates an arbitrary MIME message 224 content, together with message- and content-related metadata. This 225 can optionally be signed or encrypted using MIME security 226 multiparts in conjunction with an appropriate security scheme. 228 A message/cpim object is a multipart entity, where the first part 229 contains the message metadata and the second part is the message 230 content. The two parts are syntactically separated by a blank 231 line, to keep the message header information (with its more 232 stringent syntax rules) separate from the MIME message content 233 headers. 235 The message/cpim format is a MIME object containing two parts: 236 message headers (metadata) and message content, separated by a 237 blank line. 239 Thus, the complete message looks something like this: 241 m: Content-type: message/cpim 242 s: 243 h: (message-metadata-headers) 244 s: 245 e: (encapsulated MIME message-body) 246 CPIM Message Format 7 February 2001 247 249 The end of the message body is defined by the framing mechanism of 250 the protocol used. The tags 'm:', 's:', 'h:', 'e:', and 'x:' are 251 not part of the message format and are used here to indicate the 252 different parts of the message, thus: 254 m: MIME headers for the overall message 255 s: a blank separator line 256 h: message headers 257 e: encapsulated MIME object containing the message content 258 x: MIME security multipart message wrapper 260 2.1 Message/cpim MIME headers 262 The message MIME headers identify the message as a CPIM-formatted 263 message. The only required header is: 265 Content-type: message/cpim 267 Other MIME headers may be used as appropriate for the message 268 transfer environment. 270 2.2 Message headers 272 Message headers carry information relevant to the end-to-end 273 transfer of the message of the message from sender to receiver. 274 Message headers MUST NOT be modified or reformatted in transit, but 275 in some circumstances they MAY be examined by a CPIM message 276 transfer protocol. 278 The message headers serve a similar purpose to RFC822 message 279 headers in email [2], and have a similar but restricted allowable 280 syntax. 282 The basic header syntax is: 284 Key: Value 286 where "Key" is a header name and "Value" is the corresponding 287 header value. The following considerations apply: 289 o The entire header MUST be contained on a single line. The line 290 terminator is not considered part of the header value. 292 o Only one header per line. Multiple headers MUST NOT be included 293 on a single line. 295 o Processors SHOULD NOT impose any line-length limitations. 297 o There MUST NOT be any whitespace at the beginning or end of a 298 line. 300 CPIM Message Format 7 February 2001 301 303 o UTF-8 character encoding [21] MUST be used throughout. 305 o The character sequence CR,LF (13,10) MUST be used to terminate 306 each line. 308 o The header name contains only US-ASCII characters (see later for 309 the specific syntax) 311 o The header MUST NOT contain any control characters (0-31). If a 312 header value needs to represent control characters then a 313 suitable escape mechanism must be defined. 315 [[[???define a standard escape mechanism??? If so, what about 316 URIs, and other objects with their own defined mechanisms???]]] 318 o There MUST be a single space character (32) following the header 319 name and colon. 321 o Multiple headers using the same key (header name) are allowed. 322 (Specific header semantics may dictate only one occurrence of any 323 particular header.) 325 o Headers names are case-sensitive. 327 o Case-sensitivity of the header values are dependent on the 328 particular header definition. Message processors MUST preserve 329 the case of all headers (both the header name and header value). 331 o The order of headers is not generally significant, except 332 possibly where there are multiple occurrences of a given header 333 name. Message processors MUST preserve the ordering of message 334 headers. 336 Examples: 338 To: Pooh Bear 339 From: 340 Date: 2001-02-02T10:48:54-05:00 342 2.3 Message content 344 The final section of a message/cpim is the MIME-encapsulated 345 message content, which follows standard MIME formatting rules 346 [3,4]. 348 The MIME content headers MUST include at least a Content-Type 349 header. The content may be any MIME type. 351 CPIM Message Format 7 February 2001 352 354 Example: 356 Content-Type: text/plain; charset=utf-8 357 Content-ID: <1234567890@foo.com> 359 This is my encapsulated text message content 361 3. MESSAGE HEADER SYNTAX 363 A header is made of two parts, a name and a value, separated by a 364 colon character (':') followed by a single space (32), and 365 terminated by a sequence of CR,LF (13,10). 367 Headers use UTF-8 character encoding thoughout, per RFC 2279 [21]. 369 3.1 Header names 371 The header name is a sequence of US-ASCII characters, excluding 372 control characters, SPACE or separator characters. Use of the 373 character "." in a header name is reserved for a namespace prefix 374 separator. 376 Separator characters are: 378 SEPARATORS = "(" / ")" / "<" / ">" / "@" 379 / "," / ";" / ":" / "\" / <"> 380 / "/" / "[" / "]" / "?" / "=" 381 / "{" / "}" / SP 383 NOTE: the range of allowed characters was determined by 384 examination of HTTP and RFC822 header name formats and 385 choosing the more resticted. The intent is to allow CPIM 386 headers to follow a syntax that is compatible with the 387 allowed syntax for both RFC 822 [2] and HTTP [18] 388 (including HTTP-derived protocols such as SIP). 390 3.2 Header Value 392 A header value has a structure defined by the corresponding header 393 specification. Implementations that use a particular header must 394 adhere to the format and usage rules thus defined when creating or 395 processing a message containing that header. 397 The other general constraints on hjeader formats MUST also be 398 followed (one line, UTF-8 character encoding, no control 399 characters, etc.) 400 CPIM Message Format 7 February 2001 401 403 3.3 Language Tagging 405 Full internationalization of a protocol requires that a language 406 can be indicated for any human-readable text [6,19]. 408 A message header may indicate a language for the associated value 409 by including a language parameter ';lang=tag' after the header name 410 and preceding the colon, where 'tag' is a language identifying 411 token per RFC 3066 [7]. 413 Example: 415 Subject;lang=fr: Subjet de message 417 If the language parameter is not applied a header, any human- 418 readable text is assumed to use the language identified as 419 'i-default' [19]. 421 3.4 Namespaces for header name extensibility 423 NOTE: this section defines a framework for header 424 extensibility whose use is optional. If no header 425 extensions are allowed by an application then these 426 structures may never be used. 428 An application that uses this message format is expected to define 429 the set of headers that are required and allowed for that 430 application. This section defines a header extensibility framework 431 that can be used with any application. 433 The extensibility framework is based on that provided for XML [11] 434 by XML namespaces [12]. All headers are associated with a 435 "namespace", which is in turn associated with a globally unique 436 URI. Within a particular message instance, header names are 437 associated with a particular namespace through the presence or 438 absence of a namespace prefix, which is a leading part of the 439 header name followed by a period ("."); e.g. 441 prefix.header-name: header-value 443 Here, 'prefix' is the header name prefix, 'header-name' is the 444 header name within the namespace associated with 'prefix', and 445 'header-value' is the value for this header. 447 header-name: header-value 449 In this case, the header name prefix is absent, and the given 450 'header-name' is associated with a default namespace. 452 CPIM Message Format 7 February 2001 453 455 An application that uses this format designates a default namespace 456 for any headers that are not more explicitly associated with any 457 namespace. In many cases, the default namespace may be all that is 458 needed. 460 A namespace is identified by a URI. In this usage, the URI is used 461 simply as a globally unique identifier, and there is no requirement 462 that it can be used for any other purpose. Any legal globally 463 unique URI MAY be used to identify a namespace (by "globally 464 unique", we mean constructed according to some set of rules so that 465 it is reasonable to expect that nobody else will use the same URI 466 for a different purpose). A URI used as an identifier MUST be a 467 full absolute-URI, per RFC 2396 [10]. (Relative URIs and URI- 468 references containing fragment identifiers MUST NOT be used for 469 this purpose.) 471 Within a specific message, a 'NS' header is used to declare a 472 namespace prefix and associate it with a URI that identifies a 473 namespace. Following that declaration, within the scope of that 474 message, the combination of namespace prefix and header name 475 indicates a globally unique identifier for the header (consisting 476 of the namespace URI and header name). For example: 478 NS: MyFeatures 479 MyFeatures.WackyMessageOption: Use-silly-font 481 This defines a namespace prefix 'MyFeatures' associated with the 482 namespace identifier 'mid:MessageFeatures@id.foo.com'. 483 Subsequently the prefix indicates that the WackyMessageOption 484 header name referenced is associated with the identified namespace. 486 A namespace prefix declaration MUST precede any use of that prefix. 488 CPIM Message Format 7 February 2001 489 491 With the exception of any application-specific predefined namespace 492 prefixes (see section 6), a namespace prefix is strictly local to 493 the message in which it occurs. The actual prefix used has no 494 global significance. Thus, the headers: 496 xxx.name: value 498 yyy.name: value 500 in two different messages may have exactly the same effect if 501 namespace prefixes 'xxx' and 'yyy' are associated with the same 502 namespace URI. Thus the following have exactly the same meaning: 504 NS: acme 505 acme.runner-trap: set 507 and 509 NS: widget 510 widget.runner-trap: set 512 A 'NS' header without a header prefix name specifies a default 513 namespace for subsequent headers; that is a namespace that is 514 associated with header names not having a prefix. For example: 516 NS: 517 runner-trap: set 519 has the same meaning as the previous examples. 521 This framework allows different implementors to create extension 522 headers without the worry of header name duplication; each defines 523 headers within their own namespace. 525 3.5 Mandatory-to-recognize features 527 Sometimes it is necessary for the sender of a message to insist 528 that some functionality is understood by the recipient. By using 529 the mandatory-to-recognize indicator, a sender is notifying the 530 recipient that it MUST understand the named header or feature in 531 order to properly understand the message. 533 A header or feature is indicated as being mandatory-to-recognize by 534 a 'Require' header. For example: 536 Require: MyFeatures.VitalMessageOption 537 MyFeatures.VitalMessageOption: Confirmation-requested 539 Multiple required header names may be listed in a single 'Require' 540 header, separated by commas. 542 CPIM Message Format 7 February 2001 543 545 Note that indiscriminate use of required headers could harm 546 interoperability. It is suggested that any implementator who 547 defines required headers also publish the header specifications so 548 other implementations can succesfully interoperate. 550 The 'Require' header MAY also be used to indicate that some non- 551 header semantics must be implemented by the recipient, even when it 552 does not appear as a header. For example: 554 Require: Locale.MustRenderKanji 556 might be used to indicate that message content includes characters 557 from the Kanji repertoire, which must be rendered for proper 558 understanding of the message. In this case, the header name is 559 just a token (using header name syntax and namespace association) 560 that indicates some desired behaviour. 562 3.6 Collected message header syntax 564 The following description of message header syntax uses ABNF, per 565 RFC 2234 [17]. 567 Header = Header-name *( ";" Parameter ) ": " 568 Header-value 569 CRLF 571 Header-name = [ Name-prefix "." ] Name 572 Name-prefix = Token 573 Name = Token 575 Parameter = Lang-param / Ext-param 576 Lang-param = "lang=" Language-tag 577 Ext-param = Param-name "=" Param-value 578 Param-name = Name 579 Param-value = Token / Number / String 581 Header-value = *UTF8-no-CTL 583 Token = 1*TOKENCHAR 584 Number = 1*DIGIT 585 String = DQUOTE *( Str-char / Esc-pair ) DQUOTE 586 Str-char = ( %x20-21 / %x23-5B / %x5D-7E / UTF8-multi ) 587 Esc-pair = "\" UTF8-no-CTL 588 CPIM Message Format 7 February 2001 589 591 Formal-name = 1*( Token SP ) / String 592 URI = 593 Language-tag = 594 TOKENCHAR = 595 SEPARATORS = "(" / ")" / "<" / ">" / "@" 596 / "," / ";" / ":" / "\" / <"> 597 / "/" / "[" / "]" / "?" / "=" 598 / "{" / "}" / SP 599 CTL = 600 CRLF = 601 SP = 602 DIGIT = 603 DQUOTE = 604 UTF8-no-CTL = %x20-7e / UTF8-multi 605 UTF8-multi = %xC0-DF %x80-BF 606 / %xE0-EF %x80-BF %x80-BF 607 / %xF0-F7 %x80-BF %x80-BF %x80-BF 608 / %xF8-FB %x80-BF %x80-BF %x80-BF %x80-BF 609 / %xFC-FD %x80-BF %x80-BF %x80-BF %x80-BF %x80-BF 611 4. HEADER DEFINITIONS 613 This specification defines a core set of headers that may be used 614 by CPIM applications: the application specification must indicate 615 the headers that may be used, those that must be recognized and 616 those that must be appear in any message. 618 [[[This means that the CPIM core specification must list the 619 headers that are needed and allowed for CPIM]]] 621 The header definitions that follow fall into two categories: 623 (a) those that are part of the CPIM format extensibility 624 framework, with header name prefix CPIM. 626 (b) some that have been based on similar headers in RFC 822, 627 specified here with corresponding semantics. 629 Header names and syntax are given without a namespace 630 qualification, and the associated namespace URI is listed as part 631 of the header description. Any of the namespace associations 632 already mentioned (implied default namespace, explicit default 633 namespace or implied namespace prefix or explicit namespace prefix 634 declaration) may be used to identify the namespace. 636 All headers defined here are associated with the namespace URI 637 <[[[urn:iana:cpim-headers]]]>, which is defined according to [22]. 639 CPIM Message Format 7 February 2001 640 642 4.1 The 'From' header 644 Indicates the sender of a message. 646 Header name: From 648 Namespace URI: <[[[urn:iana:cpim-headers]]]> 650 Syntax: (see also section 3.6) 652 From-header = "From" ": " [ Formal-name ] "<" URI ">" 654 Description: 656 Indicates the sender or originator of a message. 658 The 'Formal-name' identifies the person or "real world" name for 659 the originator. 661 The URI indicates an address for the originator. 663 Examples: 665 From: Winnie the Pooh 667 From: 668 CPIM Message Format 7 February 2001 669 671 4.2 The 'To' header 673 Specifies an intended recipient of a message. 675 Header name: To 677 Namespace URI: <[[[urn:iana:cpim-headers]]]> 679 Syntax: (see also section 3.6) 681 To-header = "To" ": " [ Formal-name ] "<" URI ">" 683 Description: 685 Indicates the recipient of a message. 687 The 'Formal-name' identifies the person or "real world" name for 688 the recipient. 690 The URI indicates an address for the recipient. 692 Multiple recipients may be indicated by including multiple 'To' 693 headers. 695 Examples: 697 To: Winnie the Pooh 699 To: 700 CPIM Message Format 7 February 2001 701 703 4.3 The 'cc' header 705 Specifies a non-primary recipient ("courtesy copy") for a message. 707 Header name: cc 709 Namespace URI: <[[[urn:iana:cpim-headers]]]> 711 Syntax: (see also section 3.6) 713 Cc-header = "cc" ": " [ Formal-name ] "<" URI ">" 715 Description: 717 Indicates a courtesy copy recipient of a message. 719 The 'Formal-name', if present, identifies the person or "real 720 world" name for the recipient. 722 The URI indicates an address for the recipient. 724 Multiple courtesy copy recipients may be indicated by including 725 multiple 'cc' headers. 727 Examples: 729 cc: Winnie the Pooh 731 cc: 733 4.4 The 'Date' header 735 Specifies the date and time a message was sent. 737 Header name: Date 739 Namespace URI: <[[[urn:iana:cpim-headers]]]> 741 Syntax: (see also section 8.4.1 below) 743 Date-header = "Date" ": " date-time 745 Description: 747 The 'Date' header supplies the current date and time at which the 748 sender sent the message. 750 One purpose of the this header is to provide for protection 751 against a replay attack, by allowing the recipient to know when 752 the message was intended to be sent. The value of the date 753 CPIM Message Format 7 February 2001 754 756 header is the current time at the sender when the message was 757 transmitted, using ISO 8601 date and time format as defined in 758 section 8.4.1 below. 760 Example: 762 Date: 2001-02-01T12:16:49-05:00 764 4.4.1 ISO 8601 date-and-time format 766 [[[Suggest RFC-publishing and citing Chris Newman's time-and-date 767 draft, from where this was lifted.]]] 769 The following profiles ISO 8601 [13] dates, using ABNF [17]: 771 date-fullyear = 4DIGIT 772 date-month = 2DIGIT ; 01-12 773 date-mday = 2DIGIT ; 01-28, 01-29, 01-30 or 01-31 774 time-hour = 2DIGIT ; 00-23 775 time-minute = 2DIGIT ; 00-59 776 time-second = 2DIGIT ; 00-59 or 00-60 777 time-secfrac = "." 1*DIGIT 778 time-numoffset = ("+" / "-") time-hour ":" time-minute 779 time-offset = "Z" / time-numoffset 781 partial-time = time-hour ":" time-minute ":" time-second 782 [time-secfrac] 783 full-date = date-fullyear "-" date-month "-" date-mday 784 full-time = partial-time time-offset 785 date-time = full-date "T" full-time 786 CPIM Message Format 7 February 2001 787 789 4.5 The 'Subject' header 791 Contains a description of the topic of the message. 793 Header name: Subject 795 Namespace URI: <[[[urn:iana:cpim-headers]]]> 797 Syntax: (see also section 3.6) 799 Subject-header = "Subject" [ lang-param ] ": " *UTF8-no-CTL 801 Description: 803 The 'Subject' header supplies the sender's description of the 804 topic or content of the message. 806 The sending agent should specify the language parameter if it has 807 any reasonable knowledge of the language used by the sender to 808 describe the message. 810 Example: 812 Subject;lang=en: Eeyore's feeling very depressed today 814 4.6 The 'NS' header 816 The "NS" header is used to declare a local namespace prefix. 818 Header name: NS 820 Namespace URI: <[[[urn:iana:cpim-headers]]]> 822 Syntax: (see also section 3.6) 824 NS-header = "NS" ": " [ Name-prefix ] "<" URI ">" 826 Description: 828 Declares a namespace prefix that may be used in subsequent header 829 names. See section 3.4 for more details. 831 Example: 833 NS: MyAlias 834 CPIM Message Format 7 February 2001 835 837 4.7 The 'Require' header 839 Specify a header or feature that must be implemented by the 840 receiver for correct message processing. 842 Header name: NS 844 Namespace URI: <[[[urn:iana:cpim-headers]]]> 846 Syntax: (see also section 3.6) 848 Require-header = "Require" ": " Header-name *( "," Header-name ) 850 Description: 852 Declares a namespace prefix that may be used in subsequent header 853 names. See section 3.5 for more details. 855 Note that there is no requirement that the required header 856 actually be used, but for brevity it is recommended that an 857 implemention not use issue require header for unused headers. 859 Example: 861 Require: MyAlias.VitalHeader 863 5. EXAMPLES 865 The examples in the following sections use the following per-line 866 tags to indicate different parts of the overall message format: 868 m: MIME headers for the overall message 869 s: a blank separator line 870 h: message headers 871 e: encapsulated MIME object containing the message content 872 x: MIME security multipart message wrapper 874 The following examples also assume that <[[[urn:iana:cpim- 875 headers]]]> is the implied default namespace for the application 876 concerned. 878 CPIM Message Format 7 February 2001 879 881 5.1 An example message/cpim message 883 The following example shows a message/cpim message: 885 m: Content-type: message/cpim 886 s: 887 h: From: MR SANDERS 888 h: To: Dopey Donkey 889 h: Date: 2000-12-13T13:40:00-08:00 890 h: Subject: Message subject 891 h: Subject;lang=fr: Subjet de message 892 h: NS: MyFeatures 893 h: Require: MyFeatures.VitalMessageOption 894 h: MyFeatures.VitalMessageOption: Confirmation-requested 895 h: MyFeatures.WackyMessageOption: Use-silly-font 896 s: 897 e: Content-type: text/xml; charset=utf-8 898 e: Content-ID: <1234567890@foo.com> 899 e: 900 e: 901 e: Here is the text of my message. 902 e: 904 5.2 An example using MIME multipart/signed 906 In order to secure a message/cpim, an application or implementation 907 should use RFC 1847 and some appropriate cryptographic scheme. 909 CPIM Message Format 7 February 2001 910 912 Using S/MIME and pkcs7, the above message would look like this: 914 x: Content-Type: multipart/signed; boundary=next; 915 MDALG=SHA-1; type=application/pkcs 916 x: 917 x: --next 918 m: Content-Type: message/cpim 919 s: 920 h: From: MR SANDERS 921 h: To: Dopey Donkey 922 h: Date: 2000-12-13T13:40:00-08:00 923 h: Subject: Message subject 924 h: Subject;lang=fr: Subjet de message 925 h: NS: MyFeatures 926 h: Require: MyFeatures.VitalMessageOption 927 h: MyFeatures.VitalMessageOption: Confirmation-requested 928 h: MyFeatures.WackyMessageOption: Use-silly-font 929 s: 930 e: Content-type: text/xml; charset=utf-8 931 e: Content-ID: <1234567890@foo.com> 932 e: 933 e: 934 e: Here is the text of my message. 935 e: 936 x: --next 937 x: Content-Type: application/pkcs7 938 x: 939 x: (signature stuff) 940 : 941 x: --next-- 943 6. APPLICATION DESIGN CONSIDERATIONS 945 Applications using the specification must specify: 947 o a default namespace for messages created and processed by that 948 application 950 o any namespace prefixes (in addition to CPIM) that are implicitly 951 defined for messages created and processed by that application 953 o all headers that must be recognized by implementations of the 954 application 956 o any headers that must be present in messages created by that 957 application 959 Within a network of message transfer agents, an intermediate 960 gateway MUST NOT change the message/cpim content in any way. This 961 CPIM Message Format 7 February 2001 962 964 implies that headers cannot be changed or reordered, transfer 965 encoding cannot be changed, languages cannot be changed, etc. 967 Because message/cpim messages are immutable, any transfer agent 968 that wants to modify the message should create a new message/cpim 969 message with the modified header and containing the original 970 message as its content. (This approach is similar to real-world 971 bill-of-lading handling, where each person in the chain attaches a 972 new sheet to the message. Then anyone can validate the original 973 message and see what was changed and who changed it by following 974 the trail of amendments. Another metaphor is including the old 975 message in a new envelope.) 977 7. IANA CONSIDERATIONS 979 [[[Registration template for message/cpim content type]]] 981 [[[Registration of namespace URN for CPIM headers]]] 983 8. INTERNATIONALIZATION CONSIDERATIONS 985 Message headers use UTF character encoding throughout, so can 986 convey the full UCS-4 (Unicode) character repertoire. 988 Language tagging is provided for message headers. 990 Message content is any MIME-ancapsulated content, and normal MIME 991 content internationalization considerations apply. 993 9. SECURITY CONSIDERATIONS 995 The message/cpim format is designed with security in mind. In 996 particular it is designed to be used with MIME security multiparts 997 for signatures and encryption. To this end, message/cpim messages 998 must be considered immutable once created. 1000 Because message/cpim messages are binary messages (due to UTF-8 1001 encoding), if they are transmitted across non-8-bit-clean 1002 transports then the transfer agent must tunnel the entire message. 1003 Changing the transfer encoding is not an allowable option. This 1004 implies that the message/cpim must be encapsulated by the message 1005 tranfer system and unencapsulated at the receiving end of the 1006 tunnel. 1008 The resulting message must have zero data loss due to the encoding 1009 and unencoding of the message. For example, an application may 1010 CPIM Message Format 7 February 2001 1011 1013 choose to apply the MIME base64 content-transfer-encoding to the 1014 message/cpim object to meet this requirement. 1016 10. REFERENCES 1018 [1] Bradner, S., 1019 "Key words for use in RFCs to Indicate Requirement Levels", 1020 RFC 2119, 1021 March 1997. 1023 [2] Crocker, D., 1024 "Standard for the format of ARPA Internet text messages", 1025 RFC 822, STD 11, 1026 August 1982. 1028 [3] Freed, N. and N. Borenstein, 1029 "Multipurpose Internet Mail Extensions (MIME) Part One: Format of 1030 Internet Message Bodies", 1031 RFC 2045, 1032 November 1996. 1034 [4] Freed, N. and N. Borenstein, 1035 "Multipurpose Internet Mail Extensions (MIME) Part Two: Media 1036 Types", 1037 RFC 2046 1038 November 1996. 1040 [5] Freed, N., Klensin, J., and J. Postel, 1041 "Multipurpose Internet Mail Extensions (MIME) Part Four: 1042 Registration Procedures", 1043 RFC 2048, BCP 13, 1044 November 1996. 1046 [6] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, 1047 R., Crispin, M., Svanberg, P., 1048 "Report from the IAB Character Set Workshop", 1049 RFC 2130, 1050 April 1997. 1052 [7] Alvestrand, H., 1053 "Tags for the Identification of Languages", 1054 RFC 3066, 1055 January 2001. 1056 (Defines Content-language header.) 1058 [8] Ramsdell, B., 1059 "S/MIME Version 3 Message Specification", 1060 RFC 2633, 1061 June 1999. 1063 CPIM Message Format 7 February 2001 1064 1066 [9] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, 1067 "OpenPGP Message Format", 1068 RFC 2440, 1069 November 1998. 1071 [10] Berners-Lee, T., Fielding, R.T. and L. Masinter, 1072 "Uniform Resource Identifiers (URI): Generic Syntax", 1073 RFC 2396, 1074 August 1998. 1076 [11] Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen, 1077 "Extensible Markup Language (XML) 1.0", 1078 W3C recommendation: , 1079 10 February 1998. 1081 [12] Tim Bray, Dave Hollander, and Andrew Layman 1082 "Namespaces in XML", 1083 W3C recommendation: , 1084 14 January 1999. 1086 [13] "Data elements and interchange formats _ 1087 Information interchange _ Representation of dates and times" 1088 ISO 8601:1988(E) 1089 International Organization for Standardization 1090 June 1988. 1092 [14] CPIM 1094 [15] RFC 2779: IMPP requirements 1096 [16] RFC 2231: MIME extensions for language tagging 1098 [17] RFC 2234: ABNF 1100 [18] RFC 2616: HTTP/1.1 1102 [19] Alvestrand, H, 1103 "IETF Policy on Character Sets and Languages", 1104 RFC 2277, BCP 18, 1105 January 1998. 1107 [20] Freed, N., and J. Postel, 1108 "IANA Charset Registration Procedures", 1109 BCP 19, RFC 2278, 1110 January 1998. 1112 [21] RFC 2279, UTF-8 1114 [22] IANA URN namespace: work-in-progress proposal 1115 CPIM Message Format 7 February 2001 1116 1118 11. AUTHORS' ADDRESSES 1120 Derek Atkins 1121 Telcordia Technologies 1122 6 Farragut Ave 1123 Somerville, MA 02144 1124 USA 1125 Telephone: +1 617 623 3745 1126 E-mail: warlord@research.telcordia.com 1127 E-mail: warlord@alum.mit.edu 1129 Graham Klyne 1130 Baltimore Technologies - Content Security Group, 1131 1220 Parkview, 1132 Arlington Business Park 1133 Theale 1134 Reading, RG7 4SA 1135 United Kingdom. 1136 Telephone: +44 118 930 1300 1137 Facsimile: +44 118 930 1301 1138 E-mail: GK@ACM.ORG 1140 Appendix A: Amendment history 1142 00a 01-Feb-2001 Memo initially created. 1144 00b 06-Feb-2001 Editorial review. Reworked namespace framework 1145 description. Deferred specification of mandatory 1146 headers to the application specification, allowing 1147 this document to be less application-dependent. 1148 Expanded references. Replaced some text with ABNF 1149 syntax descriptions. Reordered some major 1150 sections. 1152 00c 07-Feb-2001 Folded in some review comments. Fix up some 1153 syntax problems. Other small editorial changes. 1154 Add some references. 1156 TODO: 1158 o confirm urn namespace for headers (currently depends on a work- 1159 in-progress). 1161 o Complete IANA considerations 1163 o Finalize references 1165 o Terminology and conventions section 1166 CPIM Message Format 7 February 2001 1167 1169 REVIEW CHECKLIST: 1171 (Points to be checked or considered more widely on or before final 1172 review.) 1174 o The desirability of a completely rigid syntax. 1176 Full copyright statement 1178 Copyright (C) The Internet Society 2001. All Rights Reserved. 1180 This document and translations of it may be copied and furnished to 1181 others, and derivative works that comment on or otherwise explain 1182 it or assist in its implementation may be prepared, copied, 1183 published and distributed, in whole or in part, without restriction 1184 of any kind, provided that the above copyright notice and this 1185 paragraph are included on all such copies and derivative works. 1186 However, this document itself may not be modified in any way, such 1187 as by removing the copyright notice or references to the Internet 1188 Society or other Internet organizations, except as needed for the 1189 purpose of developing Internet standards in which case the 1190 procedures for copyrights defined in the Internet Standards process 1191 must be followed, or as required to translate it into languages 1192 other than English. 1194 The limited permissions granted above are perpetual and will not be 1195 revoked by the Internet Society or its successors or assigns. 1197 This document and the information contained herein is provided on 1198 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1199 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1200 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1201 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1202 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.