idnits 2.17.1 draft-ietf-impp-cpim-msgfmt-04.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 30 longer pages, the longest (page 1) being 66 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 == Line 490 has weird spacing: '...mespace for a...' -- 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 (5 November 2001) is 8201 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) -- Looks like a reference, but probably isn't: 'XXXX' on line 1009 == Unused Reference: '8' is defined on line 1170, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1173, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1188, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1215, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2822 (ref. '2') (Obsoleted by RFC 5322) ** 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' -- No information found for draft-thenine-im-common - is the name correct? -- Possible downref: Normative reference to a draft: 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) == Outdated reference: A later version (-14) exists of draft-mealling-iana-urn-02 == Outdated reference: A later version (-04) exists of draft-ietf-impp-datetime-03 ** Obsolete normative reference: RFC 2141 (ref. '24') (Obsoleted by RFC 8141) Summary: 15 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Atkins, Telcordia Technologies 3 Internet Draft G. Klyne, Baltimore Technologies 4 5 November 2001 5 Expires: May 2002 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 months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 To view the entire list of current Internet-Drafts, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 34 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 35 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 37 Copyright Notice 39 Copyright (C) The Internet Society 2001. All Rights Reserved. 41 Abstract 43 This memo defines the mime type 'Message/CPIM', a message format for 44 protocols that conform to the Common Profile for Instant Messaging 45 (CPIM) specification. 47 Discussion of this document 49 Please send comments to: . To subscribe: send a 50 message with the body 'subscribe' to . The 51 mailing list archive is at . 53 Table of Contents 55 1. INTRODUCTION 56 1.1 Motivation 57 1.2 Background 58 1.3 Goals 59 1.4 Terminology and conventions 60 2. OVERALL MESSAGE STRUCTURE 61 2.1 Message/CPIM MIME headers 62 2.2 Message headers 63 2.3 Character escape mechanism 64 2.4 Message content 65 3. MESSAGE HEADER SYNTAX 66 3.1 Header names 67 3.2 Header Value 68 3.3 Language Tagging 69 3.4 Namespaces for header name extensibility 70 3.5 Mandatory-to-recognize features 71 3.6 Collected message header syntax 72 4. HEADER DEFINITIONS 73 4.1 The 'From' header 74 4.2 The 'To' header 75 4.3 The 'cc' header 76 4.4 The 'DateTime' header 77 4.5 The 'Subject' header 78 4.6 The 'NS' header 79 4.7 The 'Require' header 80 5. EXAMPLES 81 5.1 An example Message/CPIM message 82 5.2 An example using MIME multipart/signed 83 6. APPLICATION DESIGN CONSIDERATIONS 84 7. IANA CONSIDERATIONS 85 7.1 Registration for Message/CPIM content type 86 7.2 Registration for urn:ietf:params:cpim-headers: 87 8. INTERNATIONALIZATION CONSIDERATIONS 88 9. SECURITY CONSIDERATIONS 89 10. ACKNOWLEDGEMENTS 90 11. REFERENCES 91 12. AUTHORS' ADDRESSES 92 Appendix A: Amendment history 93 Full copyright statement 95 1. INTRODUCTION 97 This memo defines the mime content-type 'Message/CPIM'. This is a 98 common message format for CPIM-compliant messaging protocols [14]. 100 While being prepared for CPIM, this format is quite general and may 101 be reused by other applications with similar requirements. 102 Application specifications that adopt this as a base format should 103 answer the questions raised in section 6 of this document. 105 1.1 Motivation 107 The Common Profile for Instant Messaging (CPIM) [14] specification 108 defines a number of operations to be supported and criteria to be 109 satisfied for interworking diverse instant messaging protocols. The 110 intent is to allow a variety of different protocols interworking 111 through gateways to support cross-protocol messaging that meets the 112 requirements of RFC 2779 [15]. 114 To adequately meet the security requirements of RFC 2779, a common 115 message format is needed so that end-to-end signatures and encryption 116 may be applied. This document describes a common canonical message 117 format that must be used by any CPIM-compliant message transfer 118 protocol, and over which signatures are calculated for end-to-end 119 security. 121 1.2 Background 123 RFC 2779 requires that an instant message can carry a MIME payload 124 [3,4]; thus some level of support for MIME will be a common element 125 of any CPIM compliant protocol. Therefore it seems reasonable that a 126 common message format should use a MIME/RFC822 syntax, as protocol 127 implementations must already contain code to parse this. 129 Unfortunately, using pure RFC2822/MIME [2] can be problematic: 131 o Irregular lexical structure -- RFC2822 allows a number of optional 132 encodings and multiple ways to encode a particular value. For 133 example RFC2822 comments may be encoded in multiple ways. For 134 security purposes, a single encoding method must be defined as a 135 basis for computing message digest values. Protocols that 136 transmit data in a different format would otherwise lose 137 information needed to verify a signature. 139 o Weak internationalization -- RFC2822 requires header values to use 140 7-bit ASCII, which is problematic for encoding international 141 character sets. Mechanisms for language tagging in RFC2822 142 headers [16] are awkward to use and have limited applicability. 144 o Mutability -- addition, modification or removal of header 145 information. Because it is not explicitly forbidden, many 146 applications that process MIME content (e.g. MIME gateways) 147 rebuild or restructure messages in transit. This obliterates most 148 attempt at achieving security (e.g. signatures), leaving receiving 149 applications unable to verify the received data. 151 o Message and payload separation -- there is not a clear syntactic 152 distinction between message metadata and message content. 154 o Limited extensibility (X-headers are problematic). 156 o No support for structured information (text string values only). 158 o Some processors impose line length limitations The message format 159 defined by this memo overcomes some of these difficulties by 160 having a syntax that is generally compatible with the format 161 accepted by MIME/RFC822 parsers, but simplified, and having a 162 stricter syntax. It also defines mechanisms to support some 163 desired features not covered by the RFC822/MIME format 164 specifications. 166 1.3 Goals 168 This specification aims to satisfy the following goals: 170 o a securable end-to-end format for a message (a canonical message 171 format for signature calculation) 173 o independent of any specific application 175 o capable of conveying a range of different address types 177 o assumes an 8-bit clean message-transfer protocol 179 o evolvable: extensible by multiple parties 181 o to clearly separate message metadata from message content 183 o a simple, regular, easily parsed syntax 185 o a compact, low-overhead format for simple messages 187 1.4 Terminology and conventions 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [1]. 193 NOTE: Comments like this provide additional nonessential 194 information about the rationale behind this document. 195 Such information is not needed for building a conformant 196 implementation, but may help those who wish to understand 197 the design in greater depth. 199 [[[Editorial comments and questions about outstanding issues are 200 provided in triple brackets like this. These working comments should 201 be resolved and removed prior to final publication.]]] 203 2. OVERALL MESSAGE STRUCTURE 205 The Message/CPIM format encapsulates an arbitrary MIME message 206 content, together with message- and content-related metadata. This 207 can optionally be signed or encrypted using MIME security multiparts 208 in conjunction with an appropriate security scheme. 210 A Message/CPIM object is a multipart entity, where the first part 211 contains the message metadata and the second part is the message 212 content. The two parts are syntactically separated by a blank line, 213 to keep the message header information (with its more stringent 214 syntax rules) separate from the MIME message content headers. 216 Thus, the complete message looks something like this: 218 m: Content-type: Message/CPIM 219 s: 220 h: (message-metadata-headers) 221 s: 222 e: (encapsulated MIME message-body) 224 The end of the message body is defined by the framing mechanism of 225 the protocol used. The tags 'm:', 's:', 'h:', 'e:', and 'x:' are not 226 part of the message format and are used here to indicate the 227 different parts of the message, thus: 229 m: MIME headers for the overall message 230 s: a blank separator line 231 h: message headers 232 e: encapsulated MIME object containing the message content 233 x: MIME security multipart message wrapper 235 2.1 Message/CPIM MIME headers 237 The message MIME headers identify the message as a CPIM-formatted 238 message. The only required header is: 240 Content-type: Message/CPIM 242 Other MIME headers may be used as appropriate for the message 243 transfer environment. 245 2.2 Message headers 247 Message headers carry information relevant to the end-to-end transfer 248 of the message from sender to receiver. Message headers MUST NOT be 249 modified, reformatted or reordered in transit, but in some 250 circumstances they MAY be examined by a CPIM message transfer 251 protocol. 253 The message headers serve a similar purpose to RFC2822 message 254 headers in email [2], and have a similar but restricted allowable 255 syntax. 257 The basic header syntax is: 259 Key: Value 261 where "Key" is a header name and "Value" is the corresponding header 262 value. The following considerations apply: 264 o The entire header MUST be contained on a single line. The line 265 terminator is not considered part of the header value. 267 o Only one header per line. Multiple headers MUST NOT be included 268 on a single line. 270 o Processors SHOULD NOT impose any line-length limitations. 272 o There MUST NOT be any whitespace at the beginning or end of a 273 line. 275 o UTF-8 character encoding [21] MUST be used throughout. 277 o The character sequence CR,LF (13,10) MUST be used to terminate 278 each line. 280 o The header name contains only US-ASCII characters (see later for 281 the specific syntax) 283 o The header MUST NOT contain any control characters (0-31). If a 284 header value needs to represent control characters then the escape 285 mechanism described below MUST be used. 287 o There MUST be a single space character (32) following the header 288 name and colon. 290 o Multiple headers using the same key (header name) are allowed. 291 (Specific header semantics may dictate only one occurrence of any 292 particular header.) 294 o Headers names MUST match exactly (i.e. "From:" and "from:" are 295 different headers). 297 o If a header name is not recognized or not understood, the header 298 should be ignored. But see also the "Requires:" header. 300 o Interpretation (e.g. equivalence) of header values is dependent on 301 the particular header definition. Message processors MUST 302 preserve exactly all octets of all headers (both name and value). 304 o Message processors MUST NOT change the order of message headers. 306 Examples: 308 To: Pooh Bear 309 From: 310 Date: 2001-02-02T10:48:54-05:00 312 2.3 Character escape mechanism 314 This mechanism MUST be used to code control characters in a header, 315 having Unicode code points in the range U+0000 to U+001f or U+007f. 316 (The escape mechanism is as used by the Java programming language.) 317 Note that the escape mechanism is applied to a UCS-2 character, NOT 318 to the octets of its UTF-8 coding. Mapping from/to UTF-8 coding is 319 performed without regard for escape sequences or character coding. 320 (The header syntax is defined so that octets corresponding to control 321 characters other than CR and LF do not appear in the output.) 322 An arbitrary UCS-2 character is escaped using the form: 324 \uxxxx 326 where: 328 \ is U+005c (backslash) 329 u is U+0075 (lower case letter U) 330 xxxx is a sequence of exactly four hexadecimal digits 331 (0-9, a-f or A-F) or 332 (U+0030-U+0039, U+0041-U+0046, or U+0061-0066) 334 The hexadecimal number 'xxxx' is the UCS code-point value of the 335 escaped character. 337 Further, the following special sequences introduced by "\" are used: 339 \\ for \ (backslash, U+005c) 340 \" for " (double quote, U+0022) 341 \' for ' (single quote, U+0027) 342 \b for backspace (U+0008) 343 \t for tab (U+0009) 344 \n for linefeed (U+000a) 345 \r for carriage return (U+000d) 347 2.3.1 Escape mechanism usage 349 When generating messages conformant with this specification: 351 o The special sequences listed above MUST be used to encode any 352 occurrence of the following characters that appear anywhere in a 353 header: backslash (U+005c), backspace (U+0008), tab (U+0009), 354 linefeed (U+000a) or carriage return (U+000d). 356 o The special sequence \' MUST be used for any occurrence of a 357 single quote (U+0027) that appears within a string delimited by 358 single quotes. 360 o The special sequence \" MUST be used for any occurrence of a 361 double quote (U+0022) that appears within a string delimited by 362 double quotes. 364 + Quote characters that delimit a string value MUST NOT be escaped. 366 o The general escape sequence \uxxxx MUST be used for any other 367 control character (U+0000 to U+0007, U+000b to U+000c, U+000e to 368 U+001f or u+007f) that appears anywhere in a header. 370 o All other characters MUST NOT be represented using an escape 371 sequence. 373 When processing a message based on this specification, the escape 374 sequence usage described above MUST be recognized. 376 Further, any other occurrence of any escape sequence described above 377 SHOULD be recognized and treated as an occurrence of the 378 corresponding Unicode character. 380 Any backslash ('\') character SHOULD be interpreted as introducing an 381 escape sequence. Any unrecognized escape sequence SHOULD be treated 382 as an instance of the character following the backslash character. 383 An isolated backslash that is the last character of a header SHOULD 384 be ignored. 386 2.4 Message content 388 The final section of a Message/CPIM is the MIME-encapsulated message 389 content, which follows standard MIME formatting rules [3,4]. 391 The MIME content headers MUST include at least a Content-Type header. 392 The content may be any MIME type. 394 Example: 396 e: Content-Type: text/plain; charset=utf-8 397 e: Content-ID: <1234567890@foo.com> 398 e: 399 e: This is my encapsulated text message content 401 3. MESSAGE HEADER SYNTAX 403 A header is made of two parts, a name and a value, separated by a 404 colon character (':') followed by a single space (32), and terminated 405 by a sequence of CR,LF (13,10). 407 Headers use UTF-8 character encoding thoughout, per RFC 2279 [21]. 409 3.1 Header names 411 The header name is a sequence of US-ASCII characters, excluding 412 control characters, SPACE or separator characters. Use of the 413 character "." in a header name is reserved for a namespace prefix 414 separator. 416 Separator characters are: 418 SEPARATORS = "(" / ")" / "<" / ">" / "@" 419 / "," / ";" / ":" / " 420 / "/" / "[" / "]" / "?" / "=" 421 / "{" / "}" / SP 423 NOTE: the range of allowed characters was determined by 424 examination of HTTP and RFC822 header name formats and 425 choosing the more resticted. The intent is to allow CPIM 426 headers to follow a syntax that is compatible with the 427 allowed syntax for both RFC 2822 [2] and HTTP [18] 428 (including HTTP-derived protocols such as SIP). 430 3.2 Header Value 432 A header value has a structure defined by the corresponding header 433 specification. Implementations that use a particular header must 434 adhere to the format and usage rules thus defined when creating or 435 processing a message containing that header. 437 The other general constraints on header formats MUST also be followed 438 (one line, UTF-8 character encoding, no control characters, etc.) 440 3.3 Language Tagging 442 Full internationalization of a protocol requires that a language can 443 be indicated for any human-readable text [6,19]. 445 A message header may indicate a language for its value by including 446 ';lang=tag' after the header name and colon, where 'tag' is a 447 language identifying token per RFC 3066 [7]. 449 Example: 451 Subject:;lang=fr Objet de message 453 If the language parameter is not applied a header, any human- 454 readable text is assumed to use the language identified as 455 'i-default' [19]. 457 3.4 Namespaces for header name extensibility 459 NOTE: this section defines a framework for header 460 extensibility whose use is optional. If no header 461 extensions are allowed by an application then these 462 structures may never be used. 464 An application that uses this message format is expected to define 465 the set of headers that are required and allowed for that 466 application. This section defines a header extensibility framework 467 that can be used with any application. 469 The extensibility framework is based on that provided for XML [11] by 470 XML namespaces [12]. All headers are associated with a "namespace", 471 which is in turn associated with a globally unique URI. 473 Within a particular message instance, header names are associated 474 with a particular namespace through the presence or absence of a 475 namespace prefix, which is a leading part of the header name followed 476 by a period ("."); e.g. 478 prefix.header-name: header-value 480 Here, 'prefix' is the header name prefix, 'header-name' is the header 481 name within the namespace associated with 'prefix', and 482 'header-value' is the value for this header. 484 header-name: header-value 486 In this case, the header name prefix is absent, and the given 487 'header-name' is associated with a default namespace. 489 The Message/CPIM media type registration designates a default 490 namespace for any headers that are not more explicitly associated 491 with any namespace. In many cases, this default namespace is all 492 that is needed. 494 A namespace is identified by a URI. In this usage, the URI is used 495 simply as a globally unique identifier, and there is no requirement 496 that it can be used for any other purpose. Any legal globally unique 497 URI MAY be used to identify a namespace. (By "globally unique", we 498 mean constructed according to some set of rules so that it is 499 reasonable to expect that nobody else will use the same URI for a 500 different purpose.) A URI used as an identifier MUST be a full 501 absolute-URI, per RFC 2396 [10]. (Relative URIs and URI- references 502 containing fragment identifiers MUST NOT be used for this purpose.) 503 Within a specific message, a 'NS' header is used to declare a 504 namespace prefix and associate it with a URI that identifies a 505 namespace. Following that declaration, within the scope of that 506 message, the combination of namespace prefix and header name 507 indicates a globally unique identifier for the header (consisting of 508 the namespace URI and header name). For example: 510 NS: MyFeatures 511 MyFeatures.WackyMessageOption: Use-silly-font 513 This defines a namespace prefix 'MyFeatures' associated with the 514 namespace identifier 'mid:MessageFeatures@id.foo.com'. Subsequently 515 the prefix indicates that the WackyMessageOption header name 516 referenced is associated with the identified namespace. 518 A namespace prefix declaration MUST precede any use of that prefix. 520 With the exception of any application-specific predefined namespace 521 prefixes (see section 6), a namespace prefix is strictly local to the 522 message in which it occurs. The actual prefix used has no global 523 significance. This means that the headers: 525 xxx.name: value 526 yyy.name: value 528 in two different messages may have exactly the same effect if 529 namespace prefixes 'xxx' and 'yyy' are associated with the same 530 namespace URI. Thus the following have exactly the same meaning: 532 NS: acme 533 acme.runner-trap: set 535 and 537 NS: widget 538 widget.runner-trap: set 540 A 'NS' header without a header prefix name specifies a default 541 namespace for subsequent headers; that is a namespace that is 542 associated with header names not having a prefix. For example: 544 NS: 545 runner-trap: set 547 has the same meaning as the previous examples. 549 This framework allows different implementers to create extension 550 headers without the worry of header name duplication; each defines 551 headers within their own namespace. 553 3.5 Mandatory-to-recognize features 555 Sometimes it is necessary for the sender of a message to insist that 556 some functionality is understood by the recipient. By using the 557 mandatory-to-recognize indicator, a sender is notifying the recipient 558 that it MUST understand the named header or feature in order to 559 properly understand the message. 561 A header or feature is indicated as being mandatory-to-recognize by a 562 'Require:' header. For example: 564 Require: MyFeatures.VitalMessageOption 565 MyFeatures.VitalMessageOption: Confirmation-requested 567 Multiple required header names may be listed in a single 'Require' 568 header, separated by commas. 570 NOTE: indiscriminate use of 'Require:' headers could 571 harm interoperability. It is suggested that any 572 implementer who defines required headers also publish the 573 header specifications so other implementations can 574 succesfully interoperate. 576 The 'Require:' header MAY also be used to indicate that some non- 577 header semantics must be implemented by the recipient, even when it 578 does not appear as a header. For example: 580 Require: Locale.MustRenderKanji 582 might be used to indicate that message content includes characters 583 from the Kanji repertoire, which must be rendered for proper 584 understanding of the message. In this case, the header name is just 585 a token (using header name syntax and namespace association) that 586 indicates some desired behaviour. 588 3.6 Collected message header syntax 590 The following description of message header syntax uses ABNF, per RFC 591 2234 [17]. Most of this syntax can be interpreted as defining UCS 592 character sequences or UTF-8 octet sequences. Alternate productions 593 at the end allow for either interpretation. 595 NOTE: specified text values MUST be used exactly as given, using 596 exactly the indicated upper- and lower-case letters. In this 597 respect, the ABNF usage here differs from RFC 2234. 599 Header = Header-name ":" *( ";" Parameter ) SP 600 Header-value 601 CRLF 603 Header-name = [ Name-prefix "." ] Name 604 Name-prefix = Name 606 Parameter = Lang-param / Ext-param 607 Lang-param = "lang=" Language-tag 608 Ext-param = Param-name "=" Param-value 609 Param-name = Name 610 Param-value = Token / Number / String 612 Header-value = *HEADERCHAR 614 Name = 1*NAMECHAR 615 Token = 1*TOKENCHAR 616 Number = 1*DIGIT 617 String = DQUOTE *( Str-char / Escape ) DQUOTE 618 Str-char = %x20-21 / %x23-5B / %x5D-7E / UCS-high 619 Escape = "\" ( "u" 4(HEXDIG) ; UCS codepoint 620 / "b" ; Backspace 621 / "t" ; Tab 622 / "n" ; Linefeed 623 / "r" ; Return 624 / DQUOTE ; Double quote 625 / "'" ; Single quote 626 / "\" ) ; Backslash 628 Formal-name = 1*( Token SP ) / String 629 URI = 630 Language-tag = 632 ; Any UCS character except CTLs, or escape 633 HEADERCHAR = UCS-no-CTL / Escape 635 ; Any US-ASCII char except ".", CTLs or SEPARATORS: 636 NAMECHAR = %21 / %23-26 / %2a-2b / %2d / %5e-60 / %7c / %7e 637 / ALPHA / DIGIT 639 ; Any UCS char except CTLs or SEPARATORS: 640 TOKENCHAR = NAMECHAR / "." / UCS-high 641 SEPARATORS = "(" / ")" / "<" / ">" / "@" ; 28/29/3c/3e/40 642 / "," / ";" / ":" / "\" / <"> ; 2c/3b/3a/5c/22 643 / "/" / "[" / "]" / "?" / "=" ; 2f/5b/5d/3f/3d 644 / "{" / "}" / SP ; 7b/7d/20 645 CTL = 646 CRLF = 647 SP = 648 DIGIT = 649 HEXDIG = 650 ALPHA = 651 DQUOTE = 653 To interpret the syntax in a general UCS character environment, use 654 the following productions: 656 UCS-no-CTL = %x20-7e / UCS-high 657 UCS-high = %x80-ffffffff 659 To interpret the syntax as defining UTF-8 coded octet sequences, use 660 the following productions: 662 UCS-no-CTL = UTF8-no-CTL 663 UCS-high = UTF8-multi 664 UTF8-no-CTL = %x20-7e / UTF8-multi 665 UTF8-multi = %xC0-DF %x80-BF 666 / %xE0-EF %x80-BF %x80-BF 667 / %xF0-F7 %x80-BF %x80-BF %x80-BF 668 / %xF8-FB %x80-BF %x80-BF %x80-BF %x80-BF 669 / %xFC-FD %x80-BF %x80-BF %x80-BF %x80-BF %x80-BF 671 4. HEADER DEFINITIONS 673 This specification defines a core set of headers that are defined and 674 available for use by applications: the application specification 675 must indicate the headers that may be used, those that must be 676 recognized and those that must appear in any message (see section 6). 678 The header definitions that follow fall into two categories: 680 (a) those that are part of the CPIM format extensibility framework, 681 and 683 (b) some that have been based on similar headers in RFC 2822 [2], 684 specified here with corresponding semantics. 686 Header names and syntax are described without a namespace 687 qualification, and the associated namespace URI is listed as part of 688 the header specification. Any of the namespace associations already 689 mentioned (implied default namespace, explicit default namespace or 690 implied namespace prefix or explicit namespace prefix declaration) 691 may be used to identify the namespace. 693 All headers defined here are associated with the namespace URI 694 , which is defined according to [22]. 696 NOTE: Header names and other text MUST be used exactly as given, 697 using exactly the indicated upper- and lower-case letters. In this 698 respect, the ABNF usage here differs from RFC 2234 [17]. 700 4.1 The 'From' header 702 Indicates the sender of a message. 704 Header name: From 706 Namespace URI: 708 Syntax: (see also section 3.6) 710 From-header = "From" ": " [ Formal-name ] "<" URI ">" 712 Description: 714 Indicates the sender or originator of a message. 716 If present, the 'Formal-name' identifies the person or "real 717 world" name for the originator. 719 The URI indicates an address for the originator. 721 Examples: 723 From: Winnie the Pooh 725 From: 727 4.2 The 'To' header 729 Specifies an intended recipient of a message. 731 Header name: To 733 Namespace URI: 735 Syntax: (see also section 3.6) 737 To-header = "To" ": " [ Formal-name ] "<" URI ">" 739 Description: 741 Indicates the recipient of a message. 743 If present, the 'Formal-name' identifies the person or "real 744 world" name for the recipient. 746 The URI indicates an address for the recipient. 748 Multiple recipients may be indicated by including multiple 'To' 749 headers. 751 Examples: 753 To: Winnie the Pooh 755 To: 757 4.3 The 'cc' header 759 Specifies a non-primary recipient ("courtesy copy") for a message. 761 Header name: cc 763 Namespace URI: 765 Syntax: (see also section 3.6) 767 Cc-header = "cc" ": " [ Formal-name ] "<" URI ">" 769 Description: 771 Indicates a courtesy copy recipient of a message. 773 If present, the 'Formal-name', if present, identifies the person 774 or "real world" name for the recipient. 776 The URI indicates an address for the recipient. 778 Multiple courtesy copy recipients may be indicated by including 779 multiple 'cc' headers. 781 Examples: 783 cc: Winnie the Pooh 785 cc: 787 4.4 The 'DateTime' header 789 Specifies the date and time a message was sent. 791 Header name: Date 793 Namespace URI: 795 Syntax: 797 DateTime-header = "DateTime" ": " date-time 799 (where the syntax of 'date-time' is a profile of ISO8601, defined 800 in "Date and Time on the Internet" [23]) 802 Description: 804 The 'Date' header supplies the current date and time at which the 805 sender sent the message. 807 One purpose of the this header is to provide for protection 808 against a replay attack, by allowing the recipient to know when 809 the message was intended to be sent. The value of the date header 810 is the current time at the sender when the message was 811 transmitted, using ISO 8601 date and time format as profiles in 812 "Date and Time on the Internet: Timestamps" [23]. 814 Example: 816 Date: 2001-02-01T12:16:49-05:00 818 4.5 The 'Subject' header 820 Contains a description of the topic of the message. 822 Header name: Subject 824 Namespace URI: 826 Syntax: (see also section 3.6) 828 Subject-header = "Subject" ":" [ ";" lang-param ] SP *HEADERCHAR 830 Description: 832 The 'Subject' header supplies the sender's description of the 833 topic or content of the message. 835 The sending agent should specify the language parameter if it has 836 any reasonable knowledge of the language used by the sender to 837 describe the message. 839 Example: 841 Subject:;lang=en Eeyore's feeling very depressed today 843 4.6 The 'NS' header 845 The "NS" header is used to declare a local namespace prefix. 847 Header name: NS 849 Namespace URI: 851 Syntax: (see also section 3.6) 853 NS-header = "NS" ": " [ Name-prefix ] "<" URI ">" 855 Description: 857 Declares a namespace prefix that may be used in subsequent header 858 names. See section 3.4 for more details. 860 Example: 862 NS: MyAlias 863 MyAlias.MyHeader: private-extension-data 865 4.7 The 'Require' header 867 Specify a header or feature that must be implemented by the receiver 868 for correct message processing. 870 Header name: Require 872 Namespace URI: 874 Syntax: (see also section 3.6) 876 Require-header = "Require" ": " Header-name *( "," Header-name ) 878 Description: 880 Declares a namespace prefix that may be used in subsequent header 881 names. See section 3.5 for more details. 883 Note that there is no requirement that the required header 884 actually be used, but for brevity it is recommended that an 885 implemention not use issue require header for unused headers. 887 Example: 889 Require: MyAlias.VitalHeader 891 5. EXAMPLES 893 The examples in the following sections use the following per-line 894 tags to indicate different parts of the overall message format: 896 m: MIME headers for the overall message 897 s: a blank separator line 898 h: message headers 899 e: encapsulated MIME object containing the message content 900 x: MIME security multipart message wrapper 902 The following examples also assume that is the implied default namespace for the application 904 concerned. 906 5.1 An example Message/CPIM message 908 The following example shows a Message/CPIM message: 910 m: Content-type: Message/CPIM 911 s: 912 h: From: MR SANDERS 913 h: To: Depressed Donkey 914 h: Date: 2000-12-13T13:40:00-08:00 915 h: Subject: the weather will be fine today 916 h: Subject:;lang=fr beau temps prevu pour aujourd'hui 917 h: NS: MyFeatures 918 h: Require: MyFeatures.VitalMessageOption 919 h: MyFeatures.VitalMessageOption: Confirmation-requested 920 h: MyFeatures.WackyMessageOption: Use-silly-font 921 s: 922 e: Content-type: text/xml; charset=utf-8 923 e: Content-ID: <1234567890@foo.com> 924 e: 925 e: 926 e: Here is the text of my message. 927 e: 929 5.2 An example using MIME multipart/signed 931 In order to secure a Message/CPIM, an application or implementation 932 should use RFC 1847 and some appropriate cryptographic scheme. 934 Using S/MIME and pkcs7, the above message would look like this: 936 x: Content-Type: multipart/signed; boundary=next; 937 MDALG=SHA-1; type=application/pkcs 938 x: 939 x: --next 940 m: Content-Type: Message/CPIM 941 s: 942 h: From: MR SANDERS 943 h: To: Dopey Donkey 944 h: Date: 2000-12-13T13:40:00-08:00 945 h: Subject: the weather will be fine today 946 h: Subject:;lang=fr beau temps prevu pour aujourd'hui 947 h: NS: MyFeatures 948 h: Require: MyFeatures.VitalMessageOption 949 h: MyFeatures.VitalMessageOption: Confirmation-requested 950 h: MyFeatures.WackyMessageOption: Use-silly-font 951 s: 953 e: Content-type: text/xml; charset=utf-8 954 e: Content-ID: <1234567890@foo.com> 955 e: 956 e: 957 e: Here is the text of my message. 958 e: 959 x: --next 960 x: Content-Type: application/pkcs7 961 x: 962 x: (signature stuff) 963 : 964 x: --next-- 966 6. APPLICATION DESIGN CONSIDERATIONS 968 As defined, the 'Message/CPIM' content type uses a default namespace 969 URI 'urn:ietf:params-cpim-headers:', and does not define any other 970 implicit namespace prefixes. Applications that have different 971 requirements should define and register a different MIME media type, 972 specify the required default namespace URI and define any implied 973 namespace prefixes as part of the media type specification. 975 Applications using this specification must also specify: 977 o all headers that must be recognized by implementations of the 978 application 980 o any headers that must be present in messages created by that 981 application. 983 o any headers that may appear more than once in a message, and how 984 they are to be interpreted (e.g. how to interpret multiple 985 'subject:' headers with different language parameter values). 987 Within a network of message transfer agents, an intermediate gateway 988 MUST NOT change the Message/CPIM content in any way. This implies 989 that headers cannot be changed or reordered, transfer encoding cannot 990 be changed, languages cannot be changed, etc. 992 Because Message/CPIM messages are immutable, any transfer agent that 993 wants to modify the message should create a new Message/CPIM message 994 with the modified header and containing the original message as its 995 content. (This approach is similar to real-world bill-of-lading 996 handling, where each person in the chain attaches a new sheet to the 997 message. Then anyone can validate the original message and see what 998 was changed and who changed it by following the trail of amendments. 999 Another metaphor is including the old message in a new envelope.) 1001 7. IANA CONSIDERATIONS 1003 This memo calls for two new IANA registrations: 1005 o A new MIME content-type value, Message/CPIM, per RFC 2048 [5]. 1006 The registration template is at section 7.1 below. 1008 o A new IANA URN sub-namespace, urn:ietf:params:cpim-headers:, per 1009 RFC [[[XXXX]]] [22]. The registration template is at section 7.2 1010 below. 1012 7.1 Registration for Message/CPIM content type 1014 To: ietf-types@iana.org 1015 Subject: Registration of MIME media type Message/CPIM 1017 MIME media type name: 1018 Message 1020 MIME subtype name: 1021 CPIM 1023 Required parameters: 1024 (None) 1026 Optional parameters: 1027 (None) 1029 Encoding considerations: 1030 Intended to be used in 8-bit clean environments, with non- 1031 transformative encoding (8-bit or binary, according to the 1032 content contained within the message; the CPIM message headers 1033 can be handled in an 8-bit text environment). 1035 This content type could be used with a 7-bit transfer 1036 environment if appropriate transfer encoding is used. NOTE 1037 that for this purpose, enclosed MIME content MUST BE treated as 1038 opaque data and encoded accordingly. Any encoding must be 1039 reversed before any enclosed MIME content can be accessed. 1041 Security considerations: 1042 The content may contain signed data, so any transfer encoding 1043 MUST BE exactly reversed before the content is processed. 1045 See also the security considerations for email messages (RFC 1046 2822 [2]). 1048 Interoperability considerations: 1049 This content format is intended to be used to exchange 1050 possibly-secured messages between different intant messaging 1051 protocols. Very strict adherence to the message format 1052 (including whitespare usage) may be needed to achieve 1053 interoperability. 1055 Published specification: 1056 RFC XXXX [this document] 1058 Applications which use this media type: 1059 Instant messaging 1061 Additional information: 1062 The default namespace URI associated with this content-type is 1063 'urn:ietf:params:cpim-headers:'. (See RFC XXXX [this document] 1064 for further details.) 1066 See also the Common Profile for Instant Messaging (CPIM) [14] 1068 Person & email address to contact for further information: 1069 G. Klyne, GK@ACM.ORG 1071 Intended usage: 1072 LIMITED USE 1074 Author/Change controller: 1075 IETF 1077 7.2 Registration for urn:ietf:params:cpim-headers: 1079 Registry name: 1080 cpim-headers 1082 Specification: 1083 RFC XXXX [this document] Additional values may be defined by 1084 standards track RFCs that update or obsolete RFC XXXX [this 1085 document]. 1087 Repository: 1088 ftp://ftp.isi.edu/in-notes/rfcXXXX.txt [this document] 1090 Index value: 1091 The index value is a CPIM message header name, which may 1092 consist of a sequence from a restricted set of US-ASCII 1093 characters, as define above. 1095 The URI for a header is formed from its name by: 1097 (a) replacing any non-URN characters (as defined by RFC 2141 1098 [24]) with the corresponding '%hh' escape sequence (per RFC 1099 2396 [10]), and 1101 (b) prepending the resulting string with 'urn:ietf:params:cpim- 1102 headers:'. 1104 Thus, the URI corresponding to the CPIM message header 'From:' 1105 would be 'urn:ietf:params:cpim-headers:From'. The URI 1106 corresponding to the (putative) CPIM message header 'Top&Tail' 1107 would be 'urn:ietf:params:cpim-headers:Top%26Tail'. 1109 8. INTERNATIONALIZATION CONSIDERATIONS 1111 Message headers use UTF-8 character encoding throughout, so can 1112 convey the full UCS-4 (Unicode, ISO/IEC 10646) character repertoire. 1114 Language tagging is provided for message headers using the "Language" 1115 parameter. 1117 Message content is any MIME-encapsulated content, and normal MIME 1118 content internationalization considerations apply. 1120 9. SECURITY CONSIDERATIONS 1122 The Message/CPIM format is designed with security in mind. In 1123 particular it is designed to be used with MIME security multiparts 1124 for signatures and encryption. To this end, Message/CPIM messages 1125 must be considered immutable once created. 1127 Because Message/CPIM messages are binary messages (due to UTF-8 1128 encoding), if they are transmitted across non-8-bit-clean transports 1129 then the transfer agent must tunnel the entire message. Changing the 1130 message data encoding is not an allowable option. This implies that 1131 the Message/CPIM must be encapsulated by the message tranfer system 1132 and unencapsulated at the receiving end of the tunnel. 1134 The resulting message must have no data loss due to the encoding and 1135 unencoding of the message. For example, an application may choose to 1136 apply the MIME base64 content-transfer-encoding to the Message/CPIM 1137 object to meet this requirement. 1139 10. ACKNOWLEDGEMENTS 1141 The authors thank the following for their helpful comments: Harald 1142 Alvestrand, Walter Houser, Leslie Daigle, [[[....]]] 1144 11. REFERENCES 1146 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1147 Levels", RFC 2119, March 1997. 1149 [2] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 1151 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1152 Extensions (MIME) Part One: Format of Internet Message Bodies", 1153 RFC 2045, November 1996. 1155 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1156 Extensions (MIME) Part Two: Media Types", RFC 2046 November 1157 1996. 1159 [5] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet 1160 Mail Extensions (MIME) Part Four: Registration Procedures", RFC 1161 2048, BCP 13, November 1996. 1163 [6] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, 1164 R., Crispin, M., Svanberg, P., "Report from the IAB Character 1165 Set Workshop", RFC 2130, April 1997. 1167 [7] Alvestrand, H., "Tags for the Identification of Languages", RFC 1168 3066, January 2001. (Defines Content-language header.) 1170 [8] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 1171 2633, June 1999. 1173 [9] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 1174 Message Format", RFC 2440, November 1998. 1176 [10] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform 1177 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1178 1998. 1180 [11] Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen, "Extensible 1181 Markup Language (XML) 1.0", W3C recommendation: 1182 , 10 February 1998. 1184 [12] Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in 1185 XML", W3C recommendation: , 1186 14 January 1999. 1188 [13] "Data elements and interchange formats - Information interchange 1189 - Representation of dates and times", ISO 8601:1988(E), 1190 International Organization for Standardization, June 1988. 1192 [14] Crocker, D.H., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, 1193 G., Rose, M.T., Rosenberg, J., Sparks, R. and H. Sugano, "A 1194 Common Profile for Instant Messaging (CPIM)", draft-thenine-im- 1195 common-00 (work in progress), August 2000. 1197 [15] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant 1198 Messaging / Presence Protocol Requirements", RFC 2779, February 1199 2000. 1201 [16] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word 1202 Extensions: Character Sets, Languages, and Continuations", RFC 1203 2231, November 1997. 1205 [17] D. Crocker, P. Overell, "Augmented BNF for Syntax 1206 Specifications: ABNF", RFC 2234, November 1997. 1208 [18] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1209 Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- 1210 HTTP/1.1", RFC 2616, June 1999. 1212 [19] Alvestrand, H, "IETF Policy on Character Sets and Languages", 1213 RFC 2277, BCP 18, January 1998. 1215 [20] Freed, N., and J. Postel, "IANA Charset Registration 1216 Procedures", BCP 19, RFC 2278, January 1998. 1218 [21] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 1219 2279 January 1998. 1221 [22] M. Mealling, L. Masinter, T. Hardie, G. Klyne, "An IETF URN Sub- 1222 namespace for Registered Protocol Parameters", draft-mealling- 1223 iana-urn-02.txt (work in progress), October 2001 1225 [23] C. Newman, G. Klyne, "Date and Time on the Internet: 1226 Timestamps", draft-ietf-impp-datetime-03.txt (work in progress), 1227 May 2001. 1229 [24] R. Moats, "URN Syntax", RFC 2141, May 1997. 1231 12. AUTHORS' ADDRESSES 1233 Derek Atkins 1234 Telcordia Technologies 1235 6 Farragut Ave 1236 Somerville, MA 02144 1237 USA. 1238 Telephone: +1 617 623 3745 1239 E-mail: warlord@research.telcordia.com 1240 E-mail: warlord@alum.mit.edu 1242 Graham Klyne 1243 MIMEsweeper Group, 1244 1310 Waterside, 1245 Arlington Business Park 1246 Theale 1247 Reading, RG7 4SA 1248 United Kingdom. 1249 Telephone: +44 118 903 8000 1250 Facsimile: +44 118 903 9000 1251 E-mail: GK@ACM.ORG 1253 Appendix A: Amendment history 1255 [[[RFC editor: please remove this appendix on publication.]]] 1257 00a 01-Feb-2001 Memo initially created. 1259 00b 06-Feb-2001 Editorial review. Reworked namespace framework 1260 description. Deferred specification of mandatory 1261 headers to the application specification, allowing 1262 this document to be less application-dependent. 1263 Expanded references. Replaced some text with ABNF 1264 syntax descriptions. Reordered some major sections. 1266 00c 07-Feb-2001 Folded in some review comments. Fix up some syntax 1267 problems. Other small editorial changes. Add some 1268 references. 1270 01a 29-Mar-2001 Incorporate review comments. State (simply) that 1271 this is a canonical end-to-end format for the purpose 1272 of signature calculation. Defined escape mechanism 1273 for control characters. Header name parameters 1274 placed after the ":". Changed name of Date: header 1275 to DateTime:. Revised syntax to separate character- 1276 level syntax from UTF-8 octet- level syntax. 1278 01b 30-Mar-2001 State explicitly that unrecognized header names 1279 should be ignored. Remove text about 1280 (non)significance of header order: simply say that 1281 order must be preserved. 1283 02a 30-May-2001 Updated reference to date/time draft. Editorial 1284 changes. 1286 03a 13-Jun-2001 Tighten up application of escape sequences. 1288 04a 05-Nov-2001 Add registration templates for Message/CPIM content 1289 type, and urn:ietf:params:cpim-headers: URN space. 1290 Update namespace identifier. Revised application 1291 design considerations to indicate that a default 1292 namespace URI and any implicit prefixes are to be 1293 specified by the MIME media type specification. 1294 Noted variation of ABNF usage from RFC 2234 (exact 1295 case only). Add reference to URN syntax (RFC 2141). 1297 TODO: 1299 o Remove remaining [[[editorial comments]]]. 1301 o Replace XXXX with assigned RFC numbers. (Note that this memo 1302 depends on [22] progressing to RFC status.) 1304 REVIEW CHECKLIST: 1306 (Points to be checked or considered more widely on or before final 1307 review.) 1309 o The desirability of a completely rigid syntax. 1311 o Escape mechanism details. 1313 Full copyright statement 1315 Copyright (C) The Internet Society 2001. All Rights Reserved. This 1316 document and translations of it may be copied and furnished to 1317 others, and derivative works that comment on or otherwise explain it 1318 or assist in its implementation may be prepared, copied, published 1319 and distributed, in whole or in part, without restriction of any 1320 kind, provided that the above copyright notice and this paragraph are 1321 included on all such copies and derivative works. 1323 However, this document itself may not be modified in any way, such as 1324 by removing the copyright notice or references to the Internet 1325 Society or other Internet organizations, except as needed for the 1326 purpose of developing Internet standards in which case the procedures 1327 for copyrights defined in the Internet Standards process must be 1328 followed, or as required to translate it into languages other than 1329 English. 1331 The limited permissions granted above are perpetual and will not be 1332 revoked by the Internet Society or its successors or assigns. This 1333 document and the information contained herein is provided on an "AS 1334 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1335 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1336 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1337 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1338 OR FITNESS FOR A PARTICULAR PURPOSE.