idnits 2.17.1 draft-ietf-impp-cpim-msgfmt-06.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 59 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 485 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 (20 February 2002) is 8099 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 1006 == Unused Reference: '8' is defined on line 1168, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1171, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1213, 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, IHTFP Consulting 3 Internet Draft G. Klyne, MIMEsweeper Group 4 20 February 2002 5 Expires: August 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 Copyright Notice 33 Copyright (C) The Internet Society 2002. All Rights Reserved. 35 Abstract 37 This memo defines the mime type 'Message/CPIM', a message format for 38 protocols that conform to the Common Profile for Instant Messaging 39 (CPIM) specification. 41 Discussion of this document 43 Please send comments to: . To subscribe: send a 44 message with the body 'subscribe' to . The 45 mailing list archive is at . 47 Table of Contents 49 1. INTRODUCTION 50 1.1 Motivation 51 1.2 Background 52 1.3 Goals 53 1.4 Terminology and conventions 54 2. OVERALL MESSAGE STRUCTURE 55 2.1 Message/CPIM MIME headers 56 2.2 Message headers 57 2.3 Character escape mechanism 58 2.4 Message content 59 3. MESSAGE HEADER SYNTAX 60 3.1 Header names 61 3.2 Header Value 62 3.3 Language Tagging 63 3.4 Namespaces for header name extensibility 64 3.5 Mandatory-to-recognize features 65 3.6 Collected message header syntax 66 4. HEADER DEFINITIONS 67 4.1 The 'From' header 68 4.2 The 'To' header 69 4.3 The 'cc' header 70 4.4 The 'DateTime' header 71 4.5 The 'Subject' header 72 4.6 The 'NS' header 73 4.7 The 'Require' header 74 5. EXAMPLES 75 5.1 An example Message/CPIM message 76 5.2 An example using MIME multipart/signed 77 6. APPLICATION DESIGN CONSIDERATIONS 78 7. IANA CONSIDERATIONS 79 7.1 Registration for Message/CPIM content type 80 7.2 Registration for urn:ietf:params:cpim-headers: 81 8. INTERNATIONALIZATION CONSIDERATIONS 82 9. SECURITY CONSIDERATIONS 83 10. ACKNOWLEDGEMENTS 84 11. REFERENCES 85 12. AUTHORS' ADDRESSES 86 Full copyright statement 88 1. INTRODUCTION 90 This memo defines the mime content-type 'Message/CPIM'. This is a 91 common message format for CPIM-compliant messaging protocols [14]. 93 While being prepared for CPIM, this format is quite general and may 94 be reused by other applications with similar requirements. 95 Application specifications that adopt this as a base format should 96 answer the questions raised in section 6 of this document. 98 1.1 Motivation 100 The Common Profile for Instant Messaging (CPIM) [14] specification 101 defines a number of operations to be supported and criteria to be 102 satisfied for interworking diverse instant messaging protocols. The 103 intent is to allow a variety of different protocols interworking 104 through gateways to support cross-protocol messaging that meets the 105 requirements of RFC 2779 [15]. 107 To adequately meet the security requirements of RFC 2779, a common 108 message format is needed so that end-to-end signatures and encryption 109 may be applied. This document describes a common canonical message 110 format that must be used by any CPIM-compliant message transfer 111 protocol, and over which signatures are calculated for end-to-end 112 security. 114 1.2 Background 116 RFC 2779 requires that an instant message can carry a MIME payload 117 [3,4]; thus some level of support for MIME will be a common element 118 of any CPIM compliant protocol. Therefore it seems reasonable that a 119 common message format should use a RFC2822/MIME syntax, as protocol 120 implementations must already contain code to parse this. 122 Unfortunately, using pure RFC2822/MIME [2] can be problematic: 124 o Irregular lexical structure -- RFC2822/MIME allows a number of 125 optional encodings and multiple ways to encode a particular value. 126 For example RFC2822/MIME comments may be encoded in multiple ways. 127 For security purposes, a single encoding method must be defined as 128 a basis for computing message digest values. Protocols that 129 transmit data in a different format would otherwise lose 130 information needed to verify a signature. 132 o Weak internationalization -- RFC2822/MIME requires header values 133 to use 7-bit ASCII, which is problematic for encoding 134 international character sets. Mechanisms for language tagging in 135 RFC2822/MIME headers [16] are awkward to use and have limited 136 applicability. 138 o Mutability -- addition, modification or removal of header 139 information. Because it is not explicitly forbidden, many 140 applications that process MIME content (e.g. MIME gateways) 141 rebuild or restructure messages in transit. This obliterates most 142 attempt at achieving security (e.g. signatures), leaving receiving 143 applications unable to verify the received data. 145 o Message and payload separation -- there is not a clear syntactic 146 distinction between message metadata and message content. 148 o Limited extensibility. (X-headers are problematic, because they 149 may not be standardized; this leads to situations where a header 150 starts out as experimental but then finds widespread application, 151 resulting in a common usage that cannot be standardized.) 153 o No support for structured information (text string values only). 155 o Some processors impose line length limitations. 157 The message format defined by this memo overcomes some of these 158 difficulties by having a syntax that is generally compatible with the 159 format accepted by RFC2822/MIME parsers, but simplified, and having a 160 stricter syntax. It also defines mechanisms to support some desired 161 features not covered by the RFC2822/MIME format specifications. 163 1.3 Goals 165 This specification aims to satisfy the following goals: 167 o a securable end-to-end format for a message (a canonical message 168 format for signature calculation) 170 o independent of any specific application 172 o capable of conveying a range of different address types 174 o assumes an 8-bit clean message-transfer protocol 176 o evolvable: extensible by multiple parties 178 o to clearly separate message metadata from message content 179 o a simple, regular, easily parsed syntax 181 o a compact, low-overhead format for simple messages 183 1.4 Terminology and conventions 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC 2119 [1]. 189 NOTE: Comments like this provide additional nonessential 190 information about the rationale behind this document. 191 Such information is not needed for building a conformant 192 implementation, but may help those who wish to understand 193 the design in greater depth. 195 2. OVERALL MESSAGE STRUCTURE 197 The Message/CPIM format encapsulates an arbitrary MIME message 198 content, together with message- and content-related metadata. This 199 can optionally be signed or encrypted using MIME security multiparts 200 in conjunction with an appropriate security scheme. 202 A Message/CPIM object is a multipart entity, where the first part 203 contains the message metadata and the second part is the message 204 content. The two parts are syntactically separated by a blank line, 205 to keep the message header information (with its more stringent 206 syntax rules) separate from the MIME message content headers. 208 Thus, the complete message looks something like this: 210 m: Content-type: Message/CPIM 211 s: 212 h: (message-metadata-headers) 213 s: 214 e: (encapsulated MIME message-body) 216 The end of the message body is defined by the framing mechanism of 217 the protocol used. The tags 'm:', 's:', 'h:', 'e:', and 'x:' are not 218 part of the message format and are used here to indicate the 219 different parts of the message, thus: 221 m: MIME headers for the overall message 222 s: a blank separator line 223 h: message headers 224 e: encapsulated MIME object containing the message content 225 x: MIME security multipart message wrapper 227 2.1 Message/CPIM MIME headers 229 The message MIME headers identify the message as a CPIM-formatted 230 message. The only required header is: 232 Content-type: Message/CPIM 234 Other MIME headers may be used as appropriate for the message 235 transfer environment. 237 2.2 Message headers 239 Message headers carry information relevant to the end-to-end transfer 240 of the message from sender to receiver. Message headers MUST NOT be 241 modified, reformatted or reordered in transit, but in some 242 circumstances they MAY be examined by a CPIM message transfer 243 protocol. 245 The message headers serve a similar purpose to RFC2822 message 246 headers in email [2], and have a similar but restricted allowable 247 syntax. 249 The basic header syntax is: 251 Key: Value 253 where "Key" is a header name and "Value" is the corresponding header 254 value. The following considerations apply: 256 o The entire header MUST be contained on a single line. The line 257 terminator is not considered part of the header value. 259 o Only one header per line. Multiple headers MUST NOT be included 260 on a single line. 262 o Processors SHOULD NOT impose any line-length limitations. 264 o There MUST NOT be any whitespace at the beginning or end of a 265 line. 267 o UTF-8 character encoding [21] MUST be used throughout. 269 o The character sequence CR,LF (13,10) MUST be used to terminate 270 each line. 272 o The header name contains only US-ASCII characters (see later for 273 the specific syntax) 275 o The header MUST NOT contain any control characters (0-31). If a 276 header value needs to represent control characters then the escape 277 mechanism described below MUST be used. 279 o There MUST be a single space character (32) following the header 280 name and colon. 282 o Multiple headers using the same key (header name) are allowed. 283 (Specific header semantics may dictate only one occurrence of any 284 particular header.) 286 o Headers names MUST match exactly (i.e. "From:" and "from:" are 287 different headers). 289 o If a header name is not recognized or not understood, the header 290 should be ignored. But see also the "Requires:" header. 292 o Interpretation (e.g. equivalence) of header values is dependent on 293 the particular header definition. Message processors MUST 294 preserve exactly all octets of all headers (both name and value). 296 o Message processors MUST NOT change the order of message headers. 298 Examples: 300 To: Pooh Bear 301 From: 302 DateTime: 2001-02-02T10:48:54-05:00 304 2.3 Character escape mechanism 306 This mechanism MUST be used to code control characters in a header, 307 having Unicode code points in the range U+0000 to U+001f or U+007f. 308 (Rather than invent something completely new, the escape mechanism 309 has been adopted from that used by the Java programming language.) 310 Note that the escape mechanism is applied to a UCS-2 character, NOT 311 to the octets of its UTF-8 coding. Mapping from/to UTF-8 coding is 312 performed without regard for escape sequences or character coding. 313 (The header syntax is defined so that octets corresponding to control 314 characters other than CR and LF do not appear in the output.) 316 An arbitrary UCS-2 character is escaped using the form: 318 \uxxxx 320 where: 322 \ is U+005c (backslash) 323 u is U+0075 (lower case letter U) 324 xxxx is a sequence of exactly four hexadecimal digits 325 (0-9, a-f or A-F) or 326 (U+0030-U+0039, U+0041-U+0046, or U+0061-0066) 328 The hexadecimal number 'xxxx' is the UCS code-point value of the 329 escaped character. 331 Further, the following special sequences introduced by "\" are used: 333 \\ for \ (backslash, U+005c) 334 \" for " (double quote, U+0022) 335 \' for ' (single quote, U+0027) 336 \b for backspace (U+0008) 337 \t for tab (U+0009) 338 \n for linefeed (U+000a) 339 \r for carriage return (U+000d) 341 2.3.1 Escape mechanism usage 343 When generating messages conformant with this specification: 345 o The special sequences listed above MUST be used to encode any 346 occurrence of the following characters that appear anywhere in a 347 header: backslash (U+005c), backspace (U+0008), tab (U+0009), 348 linefeed (U+000a) or carriage return (U+000d). 350 o The special sequence \' MUST be used for any occurrence of a 351 single quote (U+0027) that appears within a string delimited by 352 single quotes. 354 o The special sequence \" MUST be used for any occurrence of a 355 double quote (U+0022) that appears within a string delimited by 356 double quotes. 358 + Quote characters that delimit a string value MUST NOT be 359 escaped. 361 o The general escape sequence \uxxxx MUST be used for any other 362 control character (U+0000 to U+0007, U+000b to U+000c, U+000e to 363 U+001f or u+007f) that appears anywhere in a header. 365 o All other characters MUST NOT be represented using an escape 366 sequence. 368 When processing a message based on this specification, the escape 369 sequence usage described above MUST be recognized. 371 Further, any other occurrence of any escape sequence described above 372 SHOULD be recognized and treated as an occurrence of the 373 corresponding Unicode character. 375 Any backslash ('\') character SHOULD be interpreted as introducing an 376 escape sequence. Any unrecognized escape sequence SHOULD be treated 377 as an instance of the character following the backslash character. 378 An isolated backslash that is the last character of a header SHOULD 379 be ignored. 381 2.4 Message content 383 The final section of a Message/CPIM is the MIME-encapsulated message 384 content, which follows standard MIME formatting rules [3,4]. 386 The MIME content headers MUST include at least a Content-Type header. 387 The content may be any MIME type. 389 Example: 391 e: Content-Type: text/plain; charset=utf-8 392 e: Content-ID: <1234567890@foo.com> 393 e: 394 e: This is my encapsulated text message content 396 3. MESSAGE HEADER SYNTAX 398 A header contains two parts, a name and a value, separated by a colon 399 character (':') and single space (32). It is terminated by the 400 sequence CR,LF (13,10). 402 Headers use UTF-8 character encoding thoughout, per RFC 2279 [21]. 404 3.1 Header names 406 The header name is a sequence of US-ASCII characters, excluding 407 control characters, SPACE or separator characters. Use of the 408 character "." in a header name is reserved for a namespace prefix 409 separator. 411 Separator characters are: 413 SEPARATORS = "(" / ")" / "<" / ">" / "@" 414 / "," / ";" / ":" / "\" / <"> 415 / "/" / "[" / "]" / "?" / "=" 416 / "{" / "}" / SP 418 NOTE: the range of allowed characters was determined by 419 examination of HTTP and RFC 2822 header name formats and 420 choosing the more restricted. The intent is to allow 421 CPIM headers to follow a syntax that is compatible with 422 the allowed syntax for both RFC 2822 [2] and HTTP [18] 423 (including HTTP-derived protocols such as SIP). 425 3.2 Header Value 427 A header value has a structure defined by the corresponding header 428 specification. Implementations that use a particular header must 429 adhere to the format and usage rules thus defined when creating or 430 processing a message containing that header. 432 The other general constraints on header formats MUST also be followed 433 (one line, UTF-8 character encoding, no control characters, etc.) 435 3.3 Language Tagging 437 Full internationalization of a protocol requires that a language can 438 be indicated for any human-readable text [6,19]. 440 A message header may indicate a language for its value by including 441 ';lang=tag' after the header name and colon, where 'tag' is a 442 language identifying token per RFC 3066 [7]. 444 Example: 446 Subject:;lang=fr Objet de message 448 If the language parameter is not applied a header, any human- 449 readable text is assumed to use the language identified as 450 'i-default' [19]. 452 3.4 Namespaces for header name extensibility 454 NOTE: this section defines a framework for header 455 extensibility whose use is optional. If no header 456 extensions are allowed by an application then these 457 structures may never be used. 459 An application that uses this message format is expected to define 460 the set of headers that are required and allowed for that 461 application. This section defines a header extensibility framework 462 that can be used with any application. 464 The extensibility framework is based on that provided for XML [11] by 465 XML namespaces [12]. All headers are associated with a "namespace", 466 which is in turn associated with a globally unique URI. 468 Within a particular message instance, header names are associated 469 with a particular namespace through the presence or absence of a 470 namespace prefix, which is a leading part of the header name followed 471 by a period ("."); e.g. 473 prefix.header-name: header-value 475 Here, 'prefix' is the header name prefix, 'header-name' is the header 476 name within the namespace associated with 'prefix', and 477 'header-value' is the value for this header. 479 header-name: header-value 481 In this case, the header name prefix is absent, and the given 482 'header-name' is associated with a default namespace. 484 The Message/CPIM media type registration designates a default 485 namespace for any headers that are not more explicitly associated 486 with any namespace. In many cases, this default namespace is all 487 that is needed. 489 A namespace is identified by a URI. In this usage, the URI is used 490 simply as a globally unique identifier, and there is no requirement 491 that it can be used for any other purpose. Any legal globally unique 492 URI MAY be used to identify a namespace. (By "globally unique", we 493 mean constructed according to some set of rules so that it is 494 reasonable to expect that nobody else will use the same URI for a 495 different purpose.) A URI used as an identifier MUST be a full 496 absolute-URI, per RFC 2396 [10]. (Relative URIs and URI- references 497 containing fragment identifiers MUST NOT be used for this purpose.) 499 Within a specific message, a 'NS' header is used to declare a 500 namespace prefix and associate it with a URI that identifies a 501 namespace. Following that declaration, within the scope of that 502 message, the combination of namespace prefix and header name 503 indicates a globally unique identifier for the header (consisting of 504 the namespace URI and header name). For example: 506 NS: MyFeatures 507 MyFeatures.WackyMessageOption: Use-silly-font 509 This defines a namespace prefix 'MyFeatures' associated with the 510 namespace identifier 'mid:MessageFeatures@id.foo.com'. Subsequently 511 the prefix indicates that the WackyMessageOption header name 512 referenced is associated with the identified namespace. 514 A namespace prefix declaration MUST precede any use of that prefix. 516 With the exception of any application-specific predefined namespace 517 prefixes (see section 6), a namespace prefix is strictly local to the 518 message in which it occurs. The actual prefix used has no global 519 significance. This means that the headers: 521 xxx.name: value 522 yyy.name: value 524 in two different messages may have exactly the same effect if 525 namespace prefixes 'xxx' and 'yyy' are associated with the same 526 namespace URI. Thus the following have exactly the same meaning: 528 NS: acme 529 acme.runner-trap: set 531 and 533 NS: widget 534 widget.runner-trap: set 536 A 'NS' header without a header prefix name specifies a default 537 namespace for subsequent headers; that is a namespace that is 538 associated with header names not having a prefix. For example: 540 NS: 541 runner-trap: set 543 has the same meaning as the previous examples. 545 This framework allows different implementers to create extension 546 headers without the worry of header name duplication; each defines 547 headers within their own namespace. 549 3.5 Mandatory-to-recognize features 551 Sometimes it is necessary for the sender of a message to insist that 552 some functionality is understood by the recipient. By using the 553 mandatory-to-recognize indicator, a sender is notifying the recipient 554 that it MUST understand the named header or feature in order to 555 properly understand the message. 557 A header or feature is indicated as being mandatory-to-recognize by a 558 'Require:' header. For example: 560 Require: MyFeatures.VitalMessageOption 561 MyFeatures.VitalMessageOption: Confirmation-requested 563 Multiple required header names may be listed in a single 'Require' 564 header, separated by commas. 566 NOTE: indiscriminate use of 'Require:' headers could 567 harm interoperability. It is suggested that any 568 implementer who defines required headers also publish the 569 header specifications so other implementations can 570 succesfully interoperate. 572 The 'Require:' header MAY also be used to indicate that some non- 573 header semantics must be implemented by the recipient, even when it 574 does not appear as a header. For example: 576 Require: Locale.MustRenderKanji 578 might be used to indicate that message content includes characters 579 from the Kanji repertoire, which must be rendered for proper 580 understanding of the message. In this case, the header name is just 581 a token (using header name syntax and namespace association) that 582 indicates some desired behaviour. 584 3.6 Collected message header syntax 586 The following description of message header syntax uses ABNF, per RFC 587 2234 [17]. Most of this syntax can be interpreted as defining UCS 588 character sequences or UTF-8 octet sequences. Alternate productions 589 at the end allow for either interpretation. 591 NOTE: specified text values MUST be used exactly as given, using 592 exactly the indicated upper- and lower-case letters. In this 593 respect, the ABNF usage here differs from RFC 2234. 595 Header = Header-name ":" *( ";" Parameter ) SP 596 Header-value 597 CRLF 599 Header-name = [ Name-prefix "." ] Name 600 Name-prefix = Name 602 Parameter = Lang-param / Ext-param 603 Lang-param = "lang=" Language-tag 604 Ext-param = Param-name "=" Param-value 605 Param-name = Name 606 Param-value = Token / Number / String 608 Header-value = *HEADERCHAR 610 Name = 1*NAMECHAR 611 Token = 1*TOKENCHAR 612 Number = 1*DIGIT 613 String = DQUOTE *( Str-char / Escape ) DQUOTE 614 Str-char = %x20-21 / %x23-5B / %x5D-7E / UCS-high 615 Escape = "\" ( "u" 4(HEXDIG) ; UCS codepoint 616 / "b" ; Backspace 617 / "t" ; Tab 618 / "n" ; Linefeed 619 / "r" ; Return 620 / DQUOTE ; Double quote 621 / "'" ; Single quote 622 / "\" ) ; Backslash 624 Formal-name = 1*( Token SP ) / String 625 URI = 626 Language-tag = 628 ; Any UCS character except CTLs, or escape 629 HEADERCHAR = UCS-no-CTL / Escape 630 ; Any US-ASCII char except ".", CTLs or SEPARATORS: 631 NAMECHAR = %21 / %23-27 / %2a-2b / %2d / %5e-60 / %7c / %7e 632 / ALPHA / DIGIT 634 ; Any UCS char except CTLs or SEPARATORS: 635 TOKENCHAR = NAMECHAR / "." / UCS-high 637 SEPARATORS = "(" / ")" / "<" / ">" / "@" ; 28/29/3c/3e/40 638 / "," / ";" / ":" / "\" / <"> ; 2c/3b/3a/5c/22 639 / "/" / "[" / "]" / "?" / "=" ; 2f/5b/5d/3f/3d 640 / "{" / "}" / SP ; 7b/7d/20 641 CTL = 642 CRLF = 643 SP = 644 DIGIT = 645 HEXDIG = 646 ALPHA = 647 DQUOTE = 649 To interpret the syntax in a general UCS character environment, use 650 the following productions: 652 UCS-no-CTL = %x20-7e / UCS-high 653 UCS-high = %x80-ffffffff 655 To interpret the syntax as defining UTF-8 coded octet sequences, use 656 the following productions: 658 UCS-no-CTL = UTF8-no-CTL 659 UCS-high = UTF8-multi 660 UTF8-no-CTL = %x20-7e / UTF8-multi 661 UTF8-multi = %xC0-DF %x80-BF 662 / %xE0-EF %x80-BF %x80-BF 663 / %xF0-F7 %x80-BF %x80-BF %x80-BF 664 / %xF8-FB %x80-BF %x80-BF %x80-BF %x80-BF 665 / %xFC-FD %x80-BF %x80-BF %x80-BF %x80-BF %x80-BF 667 4. HEADER DEFINITIONS 669 This specification defines a core set of headers that are defined and 670 available for use by applications: the application specification 671 must indicate the headers that may be used, those that must be 672 recognized and those that must appear in any message (see section 6). 674 The header definitions that follow fall into two categories: 676 (a) those that are part of the CPIM format extensibility framework, 677 and 679 (b) some that have been based on similar headers in RFC 2822 [2], 680 specified here with corresponding semantics. 682 Header names and syntax are described without a namespace 683 qualification, and the associated namespace URI is listed as part of 684 the header specification. Any of the namespace associations already 685 mentioned (implied default namespace, explicit default namespace or 686 implied namespace prefix or explicit namespace prefix declaration) 687 may be used to identify the namespace. 689 All headers defined here are associated with the namespace URI 690 , which is defined according to [22]. 692 NOTE: Header names and other text MUST be used exactly as given, 693 using exactly the indicated upper- and lower-case letters. In this 694 respect, the ABNF usage here differs from RFC 2234 [17]. 696 4.1 The 'From' header 698 Indicates the sender of a message. 700 Header name: From 702 Namespace URI: 704 Syntax: (see also section 3.6) 706 From-header = "From" ": " [ Formal-name ] "<" URI ">" 708 Description: 710 Indicates the sender or originator of a message. 712 If present, the 'Formal-name' identifies the person or "real 713 world" name for the originator. 715 The URI indicates an address for the originator. 717 Examples: 719 From: Winnie the Pooh 721 From: 723 4.2 The 'To' header 725 Specifies an intended recipient of a message. 727 Header name: To 729 Namespace URI: 731 Syntax: (see also section 3.6) 733 To-header = "To" ": " [ Formal-name ] "<" URI ">" 735 Description: 737 Indicates the recipient of a message. 739 If present, the 'Formal-name' identifies the person or "real 740 world" name for the recipient. 742 The URI indicates an address for the recipient. 744 Multiple recipients may be indicated by including multiple 'To' 745 headers. 747 Examples: 749 To: Winnie the Pooh 751 To: 753 4.3 The 'cc' header 755 Specifies a non-primary recipient ("courtesy copy") for a message. 757 Header name: cc 759 Namespace URI: 761 Syntax: (see also section 3.6) 763 Cc-header = "cc" ": " [ Formal-name ] "<" URI ">" 765 Description: 767 Indicates a courtesy copy recipient of a message. 769 If present, the 'Formal-name', if present, identifies the person 770 or "real world" name for the recipient. 772 The URI indicates an address for the recipient. 774 Multiple courtesy copy recipients may be indicated by including 775 multiple 'cc' headers. 777 Examples: 779 cc: Winnie the Pooh 781 cc: 783 4.4 The 'DateTime' header 785 Specifies the date and time a message was sent. 787 Header name: DateTime 789 Namespace URI: 791 Syntax: 793 DateTime-header = "DateTime" ": " date-time 795 (where the syntax of 'date-time' is a profile of ISO8601, defined 796 in "Date and Time on the Internet" [23]) 798 Description: 800 The 'DateTime' header supplies the current date and time at which 801 the sender sent the message. 803 One purpose of the this header is to provide for protection 804 against a replay attack, by allowing the recipient to know when 805 the message was intended to be sent. The value of the date header 806 is the current time at the sender when the message was 807 transmitted, using ISO 8601 date and time format as profiles in 808 "Date and Time on the Internet: Timestamps" [23]. 810 Example: 812 DateTime: 2001-02-01T12:16:49-05:00 814 4.5 The 'Subject' header 816 Contains a description of the topic of the message. 818 Header name: Subject 820 Namespace URI: 822 Syntax: (see also section 3.6) 824 Subject-header = "Subject" ":" [ ";" lang-param ] SP *HEADERCHAR 826 Description: 828 The 'Subject' header supplies the sender's description of the 829 topic or content of the message. 831 The sending agent should specify the language parameter if it has 832 any reasonable knowledge of the language used by the sender to 833 describe the message. 835 Example: 837 Subject:;lang=en Eeyore's feeling very depressed today 839 4.6 The 'NS' header 841 The "NS" header is used to declare a local namespace prefix. 843 Header name: NS 845 Namespace URI: 847 Syntax: (see also section 3.6) 849 NS-header = "NS" ": " [ Name-prefix ] "<" URI ">" 851 Description: 853 Declares a namespace prefix that may be used in subsequent header 854 names. See section 3.4 for more details. 856 Example: 858 NS: MyAlias 859 MyAlias.MyHeader: private-extension-data 861 4.7 The 'Require' header 863 Specify a header or feature that must be implemented by the receiver 864 for correct message processing. 866 Header name: Require 868 Namespace URI: 870 Syntax: (see also section 3.6) 872 Require-header = "Require" ": " Header-name *( "," Header-name ) 874 Description: 876 Declares a namespace prefix that may be used in subsequent header 877 names. See section 3.5 for more details. 879 Note that there is no requirement that the required header 880 actually be used, but for brevity it is recommended that an 881 implemention not use issue require header for unused headers. 883 Example: 885 Require: MyAlias.VitalHeader 887 5. EXAMPLES 889 The examples in the following sections use the following per-line 890 tags to indicate different parts of the overall message format: 892 m: MIME headers for the overall message 893 s: a blank separator line 894 h: message headers 895 e: encapsulated MIME object containing the message content 896 x: MIME security multipart message wrapper 898 The following examples also assume that is the implied default namespace for the application 900 concerned. 902 5.1 An example Message/CPIM message 904 The following example shows a Message/CPIM message: 906 m: Content-type: Message/CPIM 907 s: 908 h: From: MR SANDERS 909 h: To: Depressed Donkey 910 h: DateTime: 2000-12-13T13:40:00-08:00 911 h: Subject: the weather will be fine today 912 h: Subject:;lang=fr beau temps prevu pour aujourd'hui 913 h: NS: MyFeatures 914 h: Require: MyFeatures.VitalMessageOption 915 h: MyFeatures.VitalMessageOption: Confirmation-requested 916 h: MyFeatures.WackyMessageOption: Use-silly-font 917 s: 918 e: Content-type: text/xml; charset=utf-8 919 e: Content-ID: <1234567890@foo.com> 920 e: 921 e: 922 e: Here is the text of my message. 923 e: 925 5.2 An example using MIME multipart/signed 927 In order to secure a Message/CPIM, an application or implementation 928 should use RFC 1847 and some appropriate cryptographic scheme. 930 Using S/MIME and pkcs7, the above message would look like this: 932 x: Content-Type: multipart/signed; boundary=next; 933 micalg=sha1; 934 protocol=application/pkcs7-signature 935 x: 936 x: --next 937 m: Content-Type: Message/CPIM 938 s: 939 h: From: MR SANDERS 940 h: To: Dopey Donkey 941 h: DateTime: 2000-12-13T13:40:00-08:00 942 h: Subject: the weather will be fine today 943 h: Subject:;lang=fr beau temps prevu pour aujourd'hui 944 h: NS: MyFeatures 945 h: Require: MyFeatures.VitalMessageOption 946 h: MyFeatures.VitalMessageOption: Confirmation-requested 947 h: MyFeatures.WackyMessageOption: Use-silly-font 948 s: 950 e: Content-type: text/xml; charset=utf-8 951 e: Content-ID: <1234567890@foo.com> 952 e: 953 e: 954 e: Here is the text of my message. 955 e: 956 x: --next 957 x: Content-Type: application/pkcs7-signature 958 x: 959 x: (signature stuff) 960 : 961 x: --next-- 963 6. APPLICATION DESIGN CONSIDERATIONS 965 As defined, the 'Message/CPIM' content type uses a default namespace 966 URI 'urn:ietf:params-cpim-headers:', and does not define any other 967 implicit namespace prefixes. Applications that have different 968 requirements should define and register a different MIME media type, 969 specify the required default namespace URI and define any implied 970 namespace prefixes as part of the media type specification. 972 Applications using this specification must also specify: 974 o all headers that must be recognized by implementations of the 975 application 977 o any headers that must be present in messages created by that 978 application. 980 o any headers that may appear more than once in a message, and how 981 they are to be interpreted (e.g. how to interpret multiple 982 'subject:' headers with different language parameter values). 984 Within a network of message transfer agents, an intermediate gateway 985 MUST NOT change the Message/CPIM content in any way. This implies 986 that headers cannot be changed or reordered, transfer encoding cannot 987 be changed, languages cannot be changed, etc. 989 Because Message/CPIM messages are immutable, any transfer agent that 990 wants to modify the message should create a new Message/CPIM message 991 with the modified header and containing the original message as its 992 content. (This approach is similar to real-world bill-of-lading 993 handling, where each person in the chain attaches a new sheet to the 994 message. Then anyone can validate the original message and see what 995 was changed and who changed it by following the trail of amendments. 996 Another metaphor is including the old message in a new envelope.) 998 7. IANA CONSIDERATIONS 1000 This memo calls for two new IANA registrations: 1002 o A new MIME content-type value, Message/CPIM, per RFC 2048 [5]. 1003 The registration template is at section 7.1 below. 1005 o A new IANA URN sub-namespace, urn:ietf:params:cpim-headers:, per 1006 RFC [[[XXXX]]] [22]. The registration template is at section 7.2 1007 below. 1009 7.1 Registration for Message/CPIM content type 1011 To: ietf-types@iana.org 1012 Subject: Registration of MIME media type Message/CPIM 1014 MIME media type name: 1015 Message 1017 MIME subtype name: 1018 CPIM 1020 Required parameters: 1021 (None) 1023 Optional parameters: 1024 (None) 1026 Encoding considerations: 1027 Intended to be used in 8-bit clean environments, with non- 1028 transformative encoding (8-bit or binary, according to the 1029 content contained within the message; the CPIM message headers 1030 can be handled in an 8-bit text environment). 1032 This content type could be used with a 7-bit transfer 1033 environment if appropriate transfer encoding is used. NOTE 1034 that for this purpose, enclosed MIME content MUST BE treated as 1035 opaque data and encoded accordingly. Any encoding must be 1036 reversed before any enclosed MIME content can be accessed. 1038 Security considerations: 1039 The content may contain signed data, so any transfer encoding 1040 MUST BE exactly reversed before the content is processed. 1042 See also the security considerations for email messages (RFC 1043 2822 [2]). 1045 Interoperability considerations: 1046 This content format is intended to be used to exchange 1047 possibly-secured messages between different intant messaging 1048 protocols. Very strict adherence to the message format 1049 (including whitespare usage) may be needed to achieve 1050 interoperability. 1052 Published specification: 1053 RFC XXXX [this document] 1055 Applications which use this media type: 1056 Instant messaging 1058 Additional information: 1059 The default namespace URI associated with this content-type is 1060 'urn:ietf:params:cpim-headers:'. (See RFC XXXX [this document] 1061 for further details.) 1063 See also the Common Profile for Instant Messaging (CPIM) [14] 1065 Person & email address to contact for further information: 1066 G. Klyne, GK@ACM.ORG 1068 Intended usage: 1069 LIMITED USE 1071 Author/Change controller: 1072 IETF 1074 7.2 Registration for urn:ietf:params:cpim-headers: 1076 Registry name: 1077 cpim-headers 1079 Specification: 1080 RFC XXXX [this document] Additional values may be defined by 1081 standards track RFCs that update or obsolete RFC XXXX [this 1082 document]. 1084 Repository: 1085 ftp://ftp.isi.edu/in-notes/rfcXXXX.txt [this document] 1087 Index value: 1088 The index value is a CPIM message header name, which may 1089 consist of a sequence from a restricted set of US-ASCII 1090 characters, as define above. 1092 URN Formation: 1093 The URI for a header is formed from its name by: 1095 (a) replacing any non-URN characters (as defined by RFC 2141 1096 [24]) with the corresponding '%hh' escape sequence (per RFC 1097 2396 [10]), and 1099 (b) prepending the resulting string with 'urn:ietf:params:cpim- 1100 headers:'. 1102 Thus, the URI corresponding to the CPIM message header 'From:' 1103 would be 'urn:ietf:params:cpim-headers:From'. The URI 1104 corresponding to the (putative) CPIM message header 'Top&Tail' 1105 would be 'urn:ietf:params:cpim-headers:Top%26Tail'. 1107 8. INTERNATIONALIZATION CONSIDERATIONS 1109 Message headers use UTF-8 character encoding throughout, so can 1110 convey the full UCS-4 (Unicode, ISO/IEC 10646) character repertoire. 1112 Language tagging is provided for message headers using the "Language" 1113 parameter. 1115 Message content is any MIME-encapsulated content, and normal MIME 1116 content internationalization considerations apply. 1118 9. SECURITY CONSIDERATIONS 1120 The Message/CPIM format is designed with security in mind. In 1121 particular it is designed to be used with MIME security multiparts 1122 for signatures and encryption. To this end, Message/CPIM messages 1123 must be considered immutable once created. 1125 Because Message/CPIM messages are binary messages (due to UTF-8 1126 encoding), if they are transmitted across non-8-bit-clean transports 1127 then the transfer agent must tunnel the entire message. Changing the 1128 message data encoding is not an allowable option. This implies that 1129 the Message/CPIM must be encapsulated by the message tranfer system 1130 and unencapsulated at the receiving end of the tunnel. 1132 The resulting message must have no data loss due to the encoding and 1133 unencoding of the message. For example, an application may choose to 1134 apply the MIME base64 content-transfer-encoding to the Message/CPIM 1135 object to meet this requirement. 1137 10. ACKNOWLEDGEMENTS 1139 The authors thank the following for their helpful comments: Harald 1140 Alvestrand, Walter Houser, Leslie Daigle and Mark Day. 1142 11. REFERENCES 1144 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1145 Levels", RFC 2119, March 1997. 1147 [2] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 1149 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1150 Extensions (MIME) Part One: Format of Internet Message Bodies", 1151 RFC 2045, November 1996. 1153 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1154 Extensions (MIME) Part Two: Media Types", RFC 2046 November 1155 1996. 1157 [5] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet 1158 Mail Extensions (MIME) Part Four: Registration Procedures", RFC 1159 2048, BCP 13, November 1996. 1161 [6] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, 1162 R., Crispin, M., Svanberg, P., "Report from the IAB Character 1163 Set Workshop", RFC 2130, April 1997. 1165 [7] Alvestrand, H., "Tags for the Identification of Languages", RFC 1166 3066, January 2001. (Defines Content-language header.) 1168 [8] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 1169 2633, June 1999. 1171 [9] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 1172 Message Format", RFC 2440, November 1998. 1174 [10] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform 1175 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1176 1998. 1178 [11] Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen, "Extensible 1179 Markup Language (XML) 1.0", W3C recommendation: 1180 , 10 February 1998. 1182 [12] Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in 1183 XML", W3C recommendation: , 1184 14 January 1999. 1186 [13] "Data elements and interchange formats - Information interchange 1187 - Representation of dates and times", ISO 8601:1988(E), 1188 International Organization for Standardization, June 1988. 1190 [14] Crocker, D.H., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, 1191 G., Rose, M.T., Rosenberg, J., Sparks, R. and H. Sugano, "A 1192 Common Profile for Instant Messaging (CPIM)", draft-thenine-im- 1193 common-00 (work in progress), August 2000. 1195 [15] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant 1196 Messaging / Presence Protocol Requirements", RFC 2779, February 1197 2000. 1199 [16] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word 1200 Extensions: Character Sets, Languages, and Continuations", RFC 1201 2231, November 1997. 1203 [17] D. Crocker, P. Overell, "Augmented BNF for Syntax 1204 Specifications: ABNF", RFC 2234, November 1997. 1206 [18] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1207 Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- 1208 HTTP/1.1", RFC 2616, June 1999. 1210 [19] Alvestrand, H, "IETF Policy on Character Sets and Languages", 1211 RFC 2277, BCP 18, January 1998. 1213 [20] Freed, N., and J. Postel, "IANA Charset Registration 1214 Procedures", BCP 19, RFC 2278, January 1998. 1216 [21] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 1217 2279 January 1998. 1219 [22] M. Mealling, L. Masinter, T. Hardie, G. Klyne, "An IETF URN Sub- 1220 namespace for Registered Protocol Parameters", draft-mealling- 1221 iana-urn-02.txt (work in progress), October 2001 1223 [23] C. Newman, G. Klyne, "Date and Time on the Internet: 1224 Timestamps", draft-ietf-impp-datetime-03.txt (work in progress), 1225 May 2001. 1227 [24] R. Moats, "URN Syntax", RFC 2141, May 1997. 1229 12. AUTHORS' ADDRESSES 1231 Derek Atkins 1232 IHTFP Consulting 1233 6 Farragut Ave 1234 Somerville, MA 02144 1235 USA. 1236 Telephone: +1 617 623 3745 1237 E-mail: warlord@ihtfp.com 1238 E-mail: warlord@alum.mit.edu 1240 Graham Klyne 1241 MIMEsweeper Group, 1242 1310 Waterside, 1243 Arlington Business Park 1244 Theale 1245 Reading, RG7 4SA 1246 United Kingdom. 1247 Telephone: +44 118 903 8000 1248 Facsimile: +44 118 903 9000 1249 E-mail: GK@ACM.ORG 1251 Appendix A: Amendment history 1253 [[[RFC editor: please remove this appendix on publication.]]] 1255 00a 01-Feb-2001 Memo initially created. 1257 00b 06-Feb-2001 Editorial review. Reworked namespace framework 1258 description. Deferred specification of mandatory 1259 headers to the application specification, allowing 1260 this document to be less application-dependent. 1261 Expanded references. Replaced some text with ABNF 1262 syntax descriptions. Reordered some major sections. 1264 00c 07-Feb-2001 Folded in some review comments. Fix up some syntax 1265 problems. Other small editorial changes. Add some 1266 references. 1268 01a 29-Mar-2001 Incorporate review comments. State (simply) that 1269 this is a canonical end-to-end format for the purpose 1270 of signature calculation. Defined escape mechanism 1271 for control characters. Header name parameters 1272 placed after the ":". Changed name of Date: header 1273 to DateTime:. Revised syntax to separate character- 1274 level syntax from UTF-8 octet- level syntax. 1276 01b 30-Mar-2001 State explicitly that unrecognized header names 1277 should be ignored. Remove text about 1278 (non)significance of header order: simply say that 1279 order must be preserved. 1281 02a 30-May-2001 Updated reference to date/time draft. Editorial 1282 changes. 1284 03a 13-Jun-2001 Tighten up application of escape sequences. 1286 04a 05-Nov-2001 Add registration templates for Message/CPIM content 1287 type, and urn:ietf:params:cpim-headers: URN space. 1288 Update namespace identifier. Revised application 1289 design considerations to indicate that a default 1290 namespace URI and any implicit prefixes are to be 1291 specified by the MIME media type specification. 1292 Noted variation of ABNF usage from RFC 2234 (exact 1293 case only). Add reference to URN syntax (RFC 2141). 1295 05a 06-Nov-2001 Fix typos. Complete change of 'Date:' header to 1296 'DateTime:'. Updated author affiliations. Fix up 1297 multipart/signed example. 1299 05b 31-Dec-2001 Various editorial changes in response to last-call 1300 comments: more consistent reference to RFC2822/MIME 1301 message format; slightly expanded comment on problems 1302 with X-headers; softened wording about use of Java 1303 escape mechanism to make it clearer that Java is not 1304 a normative reference here; revised phrasing of first 1305 paragraph of section 3; correct other typos. 1307 06a 20-Feb-2002 Fix definition in section 3.6 of NAMECHAR characters 1308 to include apostrophe 0x27 (following RFC 2822). Fix 1309 error in sect 3.1 definition of SEPARATORS . 1311 TODO: 1313 o Replace XXXX with assigned RFC numbers. (Note that this memo 1314 depends on [22] progressing to RFC status.) 1316 o Update references to other CPIM documents. 1318 REVIEW CHECKLIST: 1320 (Points to be checked or considered more widely on or before final 1321 review.) 1322 o The desirability of a completely rigid syntax. 1324 o Escape mechanism details. 1326 o Check references. 1328 Full copyright statement 1330 Copyright (C) The Internet Society 2002. All Rights Reserved. This 1331 document and translations of it may be copied and furnished to 1332 others, and derivative works that comment on or otherwise explain it 1333 or assist in its implementation may be prepared, copied, published 1334 and distributed, in whole or in part, without restriction of any 1335 kind, provided that the above copyright notice and this paragraph are 1336 included on all such copies and derivative works. 1338 However, this document itself may not be modified in any way, such as 1339 by removing the copyright notice or references to the Internet 1340 Society or other Internet organizations, except as needed for the 1341 purpose of developing Internet standards in which case the procedures 1342 for copyrights defined in the Internet Standards process must be 1343 followed, or as required to translate it into languages other than 1344 English. 1346 The limited permissions granted above are perpetual and will not be 1347 revoked by the Internet Society or its successors or assigns. This 1348 document and the information contained herein is provided on an "AS 1349 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1350 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1351 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1352 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1353 OR FITNESS FOR A PARTICULAR PURPOSE.