idnits 2.17.1 draft-ietf-impp-cpim-msgfmt-08.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 487 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 (9 January 2003) is 7775 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 1197, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1200, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1211, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1232, 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) ** Obsolete normative reference: RFC 3066 (ref. '7') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 2396 (ref. '10') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2234 (ref. '17') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (ref. '21') (Obsoleted by RFC 3629) == Outdated reference: A later version (-14) exists of draft-mealling-iana-urn-02 ** Obsolete normative reference: RFC 2141 (ref. '24') (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. '8') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2440 (ref. '9') (Obsoleted by RFC 4880) -- No information found for draft-thenine-im-common - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '18') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2278 (ref. '20') (Obsoleted by RFC 2978) Summary: 10 errors (**), 0 flaws (~~), 9 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, Nine by Nine 4 9 January 2003 5 Expires: July 2003 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 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 28 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 29 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Copyright Notice 33 Copyright (C) The Internet Society 2003. 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 11.1 Normative references 86 11.2 Informative references 87 12. AUTHORS' ADDRESSES 88 Full copyright statement 90 1. INTRODUCTION 92 This memo defines the mime content-type 'Message/CPIM'. This is a 93 common message format for CPIM-compliant messaging protocols [14]. 95 While being prepared for CPIM, this format is quite general and may 96 be reused by other applications with similar requirements. 97 Application specifications that adopt this as a base format should 98 answer the questions raised in section 6 of this document. 100 1.1 Motivation 102 The Common Profile for Instant Messaging (CPIM) [14] specification 103 defines a number of operations to be supported and criteria to be 104 satisfied for interworking diverse instant messaging protocols. The 105 intent is to allow a variety of different protocols interworking 106 through gateways to support cross-protocol messaging that meets the 107 requirements of RFC 2779 [15]. 109 To adequately meet the security requirements of RFC 2779, a common 110 message format is needed so that end-to-end signatures and encryption 111 may be applied. This document describes a common canonical message 112 format that must be used by any CPIM-compliant message transfer 113 protocol, and over which signatures are calculated for end-to-end 114 security. 116 1.2 Background 118 RFC 2779 requires that an instant message can carry a MIME payload 119 [3,4]; thus some level of support for MIME will be a common element 120 of any CPIM compliant protocol. Therefore it seems reasonable that a 121 common message format should use a RFC2822/MIME syntax, as protocol 122 implementations must already contain code to parse this. 124 Unfortunately, using pure RFC2822/MIME [2] can be problematic: 126 o Irregular lexical structure -- RFC2822/MIME allows a number of 127 optional encodings and multiple ways to encode a particular value. 128 For example RFC2822/MIME comments may be encoded in multiple ways. 129 For security purposes, a single encoding method must be defined as 130 a basis for computing message digest values. Protocols that 131 transmit data in a different format would otherwise lose 132 information needed to verify a signature. 134 o Weak internationalization -- RFC2822/MIME requires header values 135 to use 7-bit ASCII, which is problematic for encoding 136 international character sets. Mechanisms for language tagging in 137 RFC2822/MIME headers [16] are awkward to use and have limited 138 applicability. 140 o Mutability -- addition, modification or removal of header 141 information. Because it is not explicitly forbidden, many 142 applications that process MIME content (e.g. MIME gateways) 143 rebuild or restructure messages in transit. This obliterates most 144 attempt at achieving security (e.g. signatures), leaving receiving 145 applications unable to verify the received data. 147 o Message and payload separation -- there is not a clear syntactic 148 distinction between message metadata and message content. 150 o Limited extensibility. (X-headers are problematic, because they 151 may not be standardized; this leads to situations where a header 152 starts out as experimental but then finds widespread application, 153 resulting in a common usage that cannot be standardized.) 155 o No support for structured information (text string values only). 157 o Some processors impose line length limitations. 159 The message format defined by this memo overcomes some of these 160 difficulties by having a syntax that is generally compatible with the 161 format accepted by RFC2822/MIME parsers, but simplified, and having a 162 stricter syntax. It also defines mechanisms to support some desired 163 features not covered by the RFC2822/MIME format specifications. 165 1.3 Goals 167 This specification aims to satisfy the following goals: 169 o a securable end-to-end format for a message (a canonical message 170 format for signature calculation) 172 o independent of any specific application 174 o capable of conveying a range of different address types 176 o assumes an 8-bit clean message-transfer protocol 178 o evolvable: extensible by multiple parties 180 o to clearly separate message metadata from message content 181 o a simple, regular, easily parsed syntax 183 o a compact, low-overhead format for simple messages 185 1.4 Terminology and conventions 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in RFC 2119 [1]. 191 NOTE: Comments like this provide additional nonessential 192 information about the rationale behind this document. 193 Such information is not needed for building a conformant 194 implementation, but may help those who wish to understand 195 the design in greater depth. 197 2. OVERALL MESSAGE STRUCTURE 199 The Message/CPIM format encapsulates an arbitrary MIME message 200 content, together with message- and content-related metadata. This 201 can optionally be signed or encrypted using MIME security multiparts 202 in conjunction with an appropriate security scheme. 204 A Message/CPIM object is a multipart entity, where the first part 205 contains the message metadata and the second part is the message 206 content. The two parts are syntactically separated by a blank line, 207 to keep the message header information (with its more stringent 208 syntax rules) separate from the MIME message content headers. 210 Thus, the complete message looks something like this: 212 m: Content-type: Message/CPIM 213 s: 214 h: (message-metadata-headers) 215 s: 216 e: (encapsulated MIME message-body) 218 The end of the message body is defined by the framing mechanism of 219 the protocol used. The tags 'm:', 's:', 'h:', 'e:', and 'x:' are not 220 part of the message format and are used here to indicate the 221 different parts of the message, thus: 223 m: MIME headers for the overall message 224 s: a blank separator line 225 h: message headers 226 e: encapsulated MIME object containing the message content 227 x: MIME security multipart message wrapper 229 2.1 Message/CPIM MIME headers 231 The message MIME headers identify the message as a CPIM-formatted 232 message. The only required header is: 234 Content-type: Message/CPIM 236 Other MIME headers may be used as appropriate for the message 237 transfer environment. 239 2.2 Message headers 241 Message headers carry information relevant to the end-to-end transfer 242 of the message from sender to receiver. Message headers MUST NOT be 243 modified, reformatted or reordered in transit, but in some 244 circumstances they MAY be examined by a CPIM message transfer 245 protocol. 247 The message headers serve a similar purpose to RFC2822 message 248 headers in email [2], and have a similar but restricted allowable 249 syntax. 251 The basic header syntax is: 253 Key: Value 255 where "Key" is a header name and "Value" is the corresponding header 256 value. The following considerations apply: 258 o The entire header MUST be contained on a single line. The line 259 terminator is not considered part of the header value. 261 o Only one header per line. Multiple headers MUST NOT be included 262 on a single line. 264 o Processors SHOULD NOT impose any line-length limitations. 266 o There MUST NOT be any whitespace at the beginning or end of a 267 line. 269 o UTF-8 character encoding [21] MUST be used throughout. 271 o The character sequence CR,LF (13,10) MUST be used to terminate 272 each line. 274 o The header name contains only US-ASCII characters (see later for 275 the specific syntax) 277 o The header MUST NOT contain any control characters (0-31). If a 278 header value needs to represent control characters then the escape 279 mechanism described below MUST be used. 281 o There MUST be a single space character (32) following the header 282 name and colon. 284 o Multiple headers using the same key (header name) are allowed. 285 (Specific header semantics may dictate only one occurrence of any 286 particular header.) 288 o Headers names MUST match exactly (i.e. "From:" and "from:" are 289 different headers). 291 o If a header name is not recognized or not understood, the header 292 should be ignored. But see also the "Requires:" header. 294 o Interpretation (e.g. equivalence) of header values is dependent on 295 the particular header definition. Message processors MUST 296 preserve exactly all octets of all headers (both name and value). 298 o Message processors MUST NOT change the order of message headers. 300 Examples: 302 To: Pooh Bear 303 From: 304 DateTime: 2001-02-02T10:48:54-05:00 306 2.3 Character escape mechanism 308 This mechanism MUST be used to code control characters in a header, 309 having Unicode code points in the range U+0000 to U+001f or U+007f. 310 (Rather than invent something completely new, the escape mechanism 311 has been adopted from that used by the Java programming language.) 312 Note that the escape mechanism is applied to a UCS-2 character, NOT 313 to the octets of its UTF-8 coding. Mapping from/to UTF-8 coding is 314 performed without regard for escape sequences or character coding. 315 (The header syntax is defined so that octets corresponding to control 316 characters other than CR and LF do not appear in the output.) 318 An arbitrary UCS-2 character is escaped using the form: 320 \uxxxx 322 where: 324 \ is U+005c (backslash) 325 u is U+0075 (lower case letter U) 326 xxxx is a sequence of exactly four hexadecimal digits 327 (0-9, a-f or A-F) or 328 (U+0030-U+0039, U+0041-U+0046, or U+0061-0066) 330 The hexadecimal number 'xxxx' is the UCS code-point value of the 331 escaped character. 333 Further, the following special sequences introduced by "\" are used: 335 \\ for \ (backslash, U+005c) 336 \" for " (double quote, U+0022) 337 \' for ' (single quote, U+0027) 338 \b for backspace (U+0008) 339 \t for tab (U+0009) 340 \n for linefeed (U+000a) 341 \r for carriage return (U+000d) 343 2.3.1 Escape mechanism usage 345 When generating messages conformant with this specification: 347 o The special sequences listed above MUST be used to encode any 348 occurrence of the following characters that appear anywhere in a 349 header: backslash (U+005c), backspace (U+0008), tab (U+0009), 350 linefeed (U+000a) or carriage return (U+000d). 352 o The special sequence \' MUST be used for any occurrence of a 353 single quote (U+0027) that appears within a string delimited by 354 single quotes. 356 o The special sequence \" MUST be used for any occurrence of a 357 double quote (U+0022) that appears within a string delimited by 358 double quotes. 360 + Quote characters that delimit a string value MUST NOT be 361 escaped. 363 o The general escape sequence \uxxxx MUST be used for any other 364 control character (U+0000 to U+0007, U+000b to U+000c, U+000e to 365 U+001f or u+007f) that appears anywhere in a header. 367 o All other characters MUST NOT be represented using an escape 368 sequence. 370 When processing a message based on this specification, the escape 371 sequence usage described above MUST be recognized. 373 Further, any other occurrence of any escape sequence described above 374 SHOULD be recognized and treated as an occurrence of the 375 corresponding Unicode character. 377 Any backslash ('\') character SHOULD be interpreted as introducing an 378 escape sequence. Any unrecognized escape sequence SHOULD be treated 379 as an instance of the character following the backslash character. 380 An isolated backslash that is the last character of a header SHOULD 381 be ignored. 383 2.4 Message content 385 The final section of a Message/CPIM is the MIME-encapsulated message 386 content, which follows standard MIME formatting rules [3,4]. 388 The MIME content headers MUST include at least a Content-Type header. 389 The content may be any MIME type. 391 Example: 393 e: Content-Type: text/plain; charset=utf-8 394 e: Content-ID: <1234567890@foo.com> 395 e: 396 e: This is my encapsulated text message content 398 3. MESSAGE HEADER SYNTAX 400 A header contains two parts, a name and a value, separated by a colon 401 character (':') and single space (32). It is terminated by the 402 sequence CR,LF (13,10). 404 Headers use UTF-8 character encoding thoughout, per RFC 2279 [21]. 406 3.1 Header names 408 The header name is a sequence of US-ASCII characters, excluding 409 control characters, SPACE or separator characters. Use of the 410 character "." in a header name is reserved for a namespace prefix 411 separator. 413 Separator characters are: 415 SEPARATORS = "(" / ")" / "<" / ">" / "@" 416 / "," / ";" / ":" / "\" / <"> 417 / "/" / "[" / "]" / "?" / "=" 418 / "{" / "}" / SP 420 NOTE: the range of allowed characters was determined by 421 examination of HTTP and RFC 2822 header name formats and 422 choosing the more restricted. The intent is to allow 423 CPIM headers to follow a syntax that is compatible with 424 the allowed syntax for both RFC 2822 [2] and HTTP [18] 425 (including HTTP-derived protocols such as SIP). 427 3.2 Header Value 429 A header value has a structure defined by the corresponding header 430 specification. Implementations that use a particular header must 431 adhere to the format and usage rules thus defined when creating or 432 processing a message containing that header. 434 The other general constraints on header formats MUST also be followed 435 (one line, UTF-8 character encoding, no control characters, etc.) 437 3.3 Language Tagging 439 Full internationalization of a protocol requires that a language can 440 be indicated for any human-readable text [6,19]. 442 A message header may indicate a language for its value by including 443 ';lang=tag' after the header name and colon, where 'tag' is a 444 language identifying token per RFC 3066 [7]. 446 Example: 448 Subject:;lang=fr Objet de message 450 If the language parameter is not applied a header, any human- 451 readable text is assumed to use the language identified as 452 'i-default' [19]. 454 3.4 Namespaces for header name extensibility 456 NOTE: this section defines a framework for header 457 extensibility whose use is optional. If no header 458 extensions are allowed by an application then these 459 structures may never be used. 461 An application that uses this message format is expected to define 462 the set of headers that are required and allowed for that 463 application. This section defines a header extensibility framework 464 that can be used with any application. 466 The extensibility framework is based on that provided for XML [11] by 467 XML namespaces [12]. All headers are associated with a "namespace", 468 which is in turn associated with a globally unique URI. 470 Within a particular message instance, header names are associated 471 with a particular namespace through the presence or absence of a 472 namespace prefix, which is a leading part of the header name followed 473 by a period ("."); e.g. 475 prefix.header-name: header-value 477 Here, 'prefix' is the header name prefix, 'header-name' is the header 478 name within the namespace associated with 'prefix', and 479 'header-value' is the value for this header. 481 header-name: header-value 483 In this case, the header name prefix is absent, and the given 484 'header-name' is associated with a default namespace. 486 The Message/CPIM media type registration designates a default 487 namespace for any headers that are not more explicitly associated 488 with any namespace. In many cases, this default namespace is all 489 that is needed. 491 A namespace is identified by a URI. In this usage, the URI is used 492 simply as a globally unique identifier, and there is no requirement 493 that it can be used for any other purpose. Any legal globally unique 494 URI MAY be used to identify a namespace. (By "globally unique", we 495 mean constructed according to some set of rules so that it is 496 reasonable to expect that nobody else will use the same URI for a 497 different purpose.) A URI used as an identifier MUST be a full 498 absolute-URI, per RFC 2396 [10]. (Relative URIs and URI- references 499 containing fragment identifiers MUST NOT be used for this purpose.) 501 Within a specific message, a 'NS' header is used to declare a 502 namespace prefix and associate it with a URI that identifies a 503 namespace. Following that declaration, within the scope of that 504 message, the combination of namespace prefix and header name 505 indicates a globally unique identifier for the header (consisting of 506 the namespace URI and header name). For example: 508 NS: MyFeatures 509 MyFeatures.WackyMessageOption: Use-silly-font 511 This defines a namespace prefix 'MyFeatures' associated with the 512 namespace identifier 'mid:MessageFeatures@id.foo.com'. Subsequently 513 the prefix indicates that the WackyMessageOption header name 514 referenced is associated with the identified namespace. 516 A namespace prefix declaration MUST precede any use of that prefix. 518 With the exception of any application-specific predefined namespace 519 prefixes (see section 6), a namespace prefix is strictly local to the 520 message in which it occurs. The actual prefix used has no global 521 significance. This means that the headers: 523 xxx.name: value 524 yyy.name: value 526 in two different messages may have exactly the same effect if 527 namespace prefixes 'xxx' and 'yyy' are associated with the same 528 namespace URI. Thus the following have exactly the same meaning: 530 NS: acme 531 acme.runner-trap: set 533 and 535 NS: widget 536 widget.runner-trap: set 538 A 'NS' header without a header prefix name specifies a default 539 namespace for subsequent headers; that is a namespace that is 540 associated with header names not having a prefix. For example: 542 NS: 543 runner-trap: set 545 has the same meaning as the previous examples. 547 This framework allows different implementers to create extension 548 headers without the worry of header name duplication; each defines 549 headers within their own namespace. 551 3.5 Mandatory-to-recognize features 553 Sometimes it is necessary for the sender of a message to insist that 554 some functionality is understood by the recipient. By using the 555 mandatory-to-recognize indicator, a sender is notifying the recipient 556 that it MUST understand the named header or feature in order to 557 properly understand the message. 559 A header or feature is indicated as being mandatory-to-recognize by a 560 'Require:' header. For example: 562 Require: MyFeatures.VitalMessageOption 563 MyFeatures.VitalMessageOption: Confirmation-requested 565 Multiple required header names may be listed in a single 'Require' 566 header, separated by commas. 568 NOTE: indiscriminate use of 'Require:' headers could 569 harm interoperability. It is suggested that any 570 implementer who defines required headers also publish the 571 header specifications so other implementations can 572 succesfully interoperate. 574 The 'Require:' header MAY also be used to indicate that some non- 575 header semantics must be implemented by the recipient, even when it 576 does not appear as a header. For example: 578 Require: Locale.MustRenderKanji 580 might be used to indicate that message content includes characters 581 from the Kanji repertoire, which must be rendered for proper 582 understanding of the message. In this case, the header name is just 583 a token (using header name syntax and namespace association) that 584 indicates some desired behaviour. 586 3.6 Collected message header syntax 588 The following description of message header syntax uses ABNF, per RFC 589 2234 [17]. Most of this syntax can be interpreted as defining UCS 590 character sequences or UTF-8 octet sequences. Alternate productions 591 at the end allow for either interpretation. 593 NOTE: specified text values MUST be used exactly as given, using 594 exactly the indicated upper- and lower-case letters. In this 595 respect, the ABNF usage here differs from RFC 2234. 597 Header = Header-name ":" *( ";" Parameter ) SP 598 Header-value 599 CRLF 601 Header-name = [ Name-prefix "." ] Name 602 Name-prefix = Name 604 Parameter = Lang-param / Ext-param 605 Lang-param = "lang=" Language-tag 606 Ext-param = Param-name "=" Param-value 607 Param-name = Name 608 Param-value = Token / Number / String 610 Header-value = *HEADERCHAR 612 Name = 1*NAMECHAR 613 Token = 1*TOKENCHAR 614 Number = 1*DIGIT 615 String = DQUOTE *( Str-char / Escape ) DQUOTE 616 Str-char = %x20-21 / %x23-5B / %x5D-7E / UCS-high 617 Escape = "\" ( "u" 4(HEXDIG) ; UCS codepoint 618 / "b" ; Backspace 619 / "t" ; Tab 620 / "n" ; Linefeed 621 / "r" ; Return 622 / DQUOTE ; Double quote 623 / "'" ; Single quote 624 / "\" ) ; Backslash 626 Formal-name = 1*( Token SP ) / String 627 URI = 628 Language-tag = 630 ; Any UCS character except CTLs, or escape 631 HEADERCHAR = UCS-no-CTL / Escape 632 ; Any US-ASCII char except ".", CTLs or SEPARATORS: 633 NAMECHAR = %21 / %23-27 / %2a-2b / %2d / %5e-60 / %7c / %7e 634 / ALPHA / DIGIT 636 ; Any UCS char except CTLs or SEPARATORS: 637 TOKENCHAR = NAMECHAR / "." / UCS-high 639 SEPARATORS = "(" / ")" / "<" / ">" / "@" ; 28/29/3c/3e/40 640 / "," / ";" / ":" / "\" / <"> ; 2c/3b/3a/5c/22 641 / "/" / "[" / "]" / "?" / "=" ; 2f/5b/5d/3f/3d 642 / "{" / "}" / SP ; 7b/7d/20 643 CTL = 644 CRLF = 645 SP = 646 DIGIT = 647 HEXDIG = 648 ALPHA = 649 DQUOTE = 651 To interpret the syntax in a general UCS character environment, use 652 the following productions: 654 UCS-no-CTL = %x20-7e / UCS-high 655 UCS-high = %x80-ffffffff 657 To interpret the syntax as defining UTF-8 coded octet sequences, use 658 the following productions: 660 UCS-no-CTL = UTF8-no-CTL 661 UCS-high = UTF8-multi 662 UTF8-no-CTL = %x20-7e / UTF8-multi 663 UTF8-multi = %xC0-DF %x80-BF 664 / %xE0-EF %x80-BF %x80-BF 665 / %xF0-F7 %x80-BF %x80-BF %x80-BF 666 / %xF8-FB %x80-BF %x80-BF %x80-BF %x80-BF 667 / %xFC-FD %x80-BF %x80-BF %x80-BF %x80-BF %x80-BF 669 4. HEADER DEFINITIONS 671 This specification defines a core set of headers that are defined and 672 available for use by applications: the application specification 673 must indicate the headers that may be used, those that must be 674 recognized and those that must appear in any message (see section 6). 676 The header definitions that follow fall into two categories: 678 (a) those that are part of the CPIM format extensibility framework, 679 and 681 (b) some that have been based on similar headers in RFC 2822 [2], 682 specified here with corresponding semantics. 684 Header names and syntax are described without a namespace 685 qualification, and the associated namespace URI is listed as part of 686 the header specification. Any of the namespace associations already 687 mentioned (implied default namespace, explicit default namespace or 688 implied namespace prefix or explicit namespace prefix declaration) 689 may be used to identify the namespace. 691 All headers defined here are associated with the namespace URI 692 , which is defined according to [22]. 694 NOTE: Header names and other text MUST be used exactly as given, 695 using exactly the indicated upper- and lower-case letters. In this 696 respect, the ABNF usage here differs from RFC 2234 [17]. 698 4.1 The 'From' header 700 Indicates the sender of a message. 702 Header name: From 704 Namespace URI: 706 Syntax: (see also section 3.6) 708 From-header = "From" ": " [ Formal-name ] "<" URI ">" 710 Description: 712 Indicates the sender or originator of a message. 714 If present, the 'Formal-name' identifies the person or "real 715 world" name for the originator. 717 The URI indicates an address for the originator. 719 Examples: 721 From: Winnie the Pooh 723 From: 725 4.2 The 'To' header 727 Specifies an intended recipient of a message. 729 Header name: To 731 Namespace URI: 733 Syntax: (see also section 3.6) 735 To-header = "To" ": " [ Formal-name ] "<" URI ">" 737 Description: 739 Indicates the recipient of a message. 741 If present, the 'Formal-name' identifies the person or "real 742 world" name for the recipient. 744 The URI indicates an address for the recipient. 746 Multiple recipients may be indicated by including multiple 'To' 747 headers. 749 Examples: 751 To: Winnie the Pooh 753 To: 755 4.3 The 'cc' header 757 Specifies a non-primary recipient ("courtesy copy") for a message. 759 Header name: cc 761 Namespace URI: 763 Syntax: (see also section 3.6) 765 Cc-header = "cc" ": " [ Formal-name ] "<" URI ">" 767 Description: 769 Indicates a courtesy copy recipient of a message. 771 If present, the 'Formal-name', if present, identifies the person 772 or "real world" name for the recipient. 774 The URI indicates an address for the recipient. 776 Multiple courtesy copy recipients may be indicated by including 777 multiple 'cc' headers. 779 Examples: 781 cc: Winnie the Pooh 783 cc: 785 4.4 The 'DateTime' header 787 Specifies the date and time a message was sent. 789 Header name: DateTime 791 Namespace URI: 793 Syntax: 795 DateTime-header = "DateTime" ": " date-time 797 (where the syntax of 'date-time' is a profile of ISO8601, defined 798 in "Date and Time on the Internet" [23]) 800 Description: 802 The 'DateTime' header supplies the current date and time at which 803 the sender sent the message. 805 One purpose of the this header is to provide for protection 806 against a replay attack, by allowing the recipient to know when 807 the message was intended to be sent. The value of the date header 808 is the current time at the sender when the message was 809 transmitted, using ISO 8601 date and time format as profiles in 810 "Date and Time on the Internet: Timestamps" [23]. 812 Example: 814 DateTime: 2001-02-01T12:16:49-05:00 816 4.5 The 'Subject' header 818 Contains a description of the topic of the message. 820 Header name: Subject 822 Namespace URI: 824 Syntax: (see also section 3.6) 826 Subject-header = "Subject" ":" [ ";" lang-param ] SP *HEADERCHAR 828 Description: 830 The 'Subject' header supplies the sender's description of the 831 topic or content of the message. 833 The sending agent should specify the language parameter if it has 834 any reasonable knowledge of the language used by the sender to 835 describe the message. 837 Example: 839 Subject:;lang=en Eeyore's feeling very depressed today 841 4.6 The 'NS' header 843 The "NS" header is used to declare a local namespace prefix. 845 Header name: NS 847 Namespace URI: 849 Syntax: (see also section 3.6) 851 NS-header = "NS" ": " [ Name-prefix ] "<" URI ">" 853 Description: 855 Declares a namespace prefix that may be used in subsequent header 856 names. See section 3.4 for more details. 858 Example: 860 NS: MyAlias 861 MyAlias.MyHeader: private-extension-data 863 4.7 The 'Require' header 865 Specify a header or feature that must be implemented by the receiver 866 for correct message processing. 868 Header name: Require 870 Namespace URI: 872 Syntax: (see also section 3.6) 874 Require-header = "Require" ": " Header-name *( "," Header-name ) 876 Description: 878 Indicates a header or feature that must be implemented or 879 understood by the receiver for correct message processing. See 880 section 3.5 for more details. 882 Note that there is no requirement that the required header 883 actually be used, but for brevity it is recommended that an 884 implemention not use issue require header for unused headers. 886 Example: 888 Require: MyAlias.VitalHeader 890 5. EXAMPLES 892 The examples in the following sections use the following per-line 893 tags to indicate different parts of the overall message format: 895 m: MIME headers for the overall message 896 s: a blank separator line 897 h: message headers 898 e: encapsulated MIME object containing the message content 899 x: MIME security multipart message wrapper 901 The following examples also assume that is the implied default namespace for the application 903 concerned. 905 5.1 An example Message/CPIM message 907 The following example shows a Message/CPIM message: 909 m: Content-type: Message/CPIM 910 s: 911 h: From: MR SANDERS 912 h: To: Depressed Donkey 913 h: DateTime: 2000-12-13T13:40:00-08:00 914 h: Subject: the weather will be fine today 915 h: Subject:;lang=fr beau temps prevu pour aujourd'hui 916 h: NS: MyFeatures 917 h: Require: MyFeatures.VitalMessageOption 918 h: MyFeatures.VitalMessageOption: Confirmation-requested 919 h: MyFeatures.WackyMessageOption: Use-silly-font 920 s: 921 e: Content-type: text/xml; charset=utf-8 922 e: Content-ID: <1234567890@foo.com> 923 e: 924 e: 925 e: Here is the text of my message. 926 e: 928 5.2 An example using MIME multipart/signed 930 In order to secure a Message/CPIM, an application or implementation 931 should use RFC 1847 and some appropriate cryptographic scheme. 933 Using S/MIME and pkcs7, the above message would look like this: 935 x: Content-Type: multipart/signed; boundary=next; 936 micalg=sha1; 937 protocol=application/pkcs7-signature 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: DateTime: 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-signature 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-IETF@ninebynine.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 URN Formation: 1096 The URI for a header is formed from its name by: 1098 (a) replacing any non-URN characters (as defined by RFC 2141 1099 [24]) with the corresponding '%hh' escape sequence (per RFC 1100 2396 [10]), and 1102 (b) prepending the resulting string with 'urn:ietf:params:cpim- 1103 headers:'. 1105 Thus, the URI corresponding to the CPIM message header 'From:' 1106 would be 'urn:ietf:params:cpim-headers:From'. The URI 1107 corresponding to the (putative) CPIM message header 'Top&Tail' 1108 would be 'urn:ietf:params:cpim-headers:Top%26Tail'. 1110 8. INTERNATIONALIZATION CONSIDERATIONS 1112 Message headers use UTF-8 character encoding throughout, so can 1113 convey the full UCS-4 (Unicode, ISO/IEC 10646) character repertoire. 1115 Language tagging is provided for message headers using the "Language" 1116 parameter. 1118 Message content is any MIME-encapsulated content, and normal MIME 1119 content internationalization considerations apply. 1121 9. SECURITY CONSIDERATIONS 1123 The Message/CPIM format is designed with security in mind. In 1124 particular it is designed to be used with MIME security multiparts 1125 for signatures and encryption. To this end, Message/CPIM messages 1126 must be considered immutable once created. 1128 Because Message/CPIM messages are binary messages (due to UTF-8 1129 encoding), if they are transmitted across non-8-bit-clean transports 1130 then the transfer agent must tunnel the entire message. Changing the 1131 message data encoding is not an allowable option. This implies that 1132 the Message/CPIM must be encapsulated by the message tranfer system 1133 and unencapsulated at the receiving end of the tunnel. 1135 The resulting message must have no data loss due to the encoding and 1136 unencoding of the message. For example, an application may choose to 1137 apply the MIME base64 content-transfer-encoding to the Message/CPIM 1138 object to meet this requirement. 1140 10. ACKNOWLEDGEMENTS 1142 The authors thank the following for their helpful comments: Harald 1143 Alvestrand, Walter Houser, Leslie Daigle, Mark Day, Brian Raymor. 1145 11. REFERENCES 1147 11.1 Normative references 1149 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1150 Levels", RFC 2119, March 1997. 1152 [2] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 1154 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1155 Extensions (MIME) Part One: Format of Internet Message Bodies", 1156 RFC 2045, November 1996. 1158 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1159 Extensions (MIME) Part Two: Media Types", RFC 2046 November 1160 1996. 1162 [5] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet 1163 Mail Extensions (MIME) Part Four: Registration Procedures", RFC 1164 2048, BCP 13, November 1996. 1166 [7] Alvestrand, H., "Tags for the Identification of Languages", RFC 1167 3066, January 2001. (Defines Content-language header.) 1169 [10] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform 1170 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1171 1998. 1173 [17] D. Crocker, P. Overell, "Augmented BNF for Syntax 1174 Specifications: ABNF", RFC 2234, November 1997. 1176 [19] Alvestrand, H, "IETF Policy on Character Sets and Languages", 1177 RFC 2277, BCP 18, January 1998. 1179 [21] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 1180 2279 January 1998. 1182 [22] M. Mealling, L. Masinter, T. Hardie, G. Klyne, "An IETF URN Sub- 1183 namespace for Registered Protocol Parameters", draft-mealling- 1184 iana-urn-02.txt (work in progress), October 2001 1186 [23] C. Newman, G. Klyne, "Date and Time on the Internet: 1187 Timestamps", RFC 3339, July 2002. 1189 [24] R. Moats, "URN Syntax", RFC 2141, May 1997. 1191 11.2 Informative references 1193 [6] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, 1194 R., Crispin, M., Svanberg, P., "Report from the IAB Character 1195 Set Workshop", RFC 2130, April 1997. 1197 [8] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 1198 2633, June 1999. 1200 [9] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 1201 Message Format", RFC 2440, November 1998. 1203 [11] Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen, "Extensible 1204 Markup Language (XML) 1.0", W3C recommendation: 1205 , 10 February 1998. 1207 [12] Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in 1208 XML", W3C recommendation: , 1209 14 January 1999. 1211 [13] "Data elements and interchange formats - Information interchange 1212 - Representation of dates and times", ISO 8601:1988(E), 1213 International Organization for Standardization, June 1988. 1215 [14] Crocker, D.H., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, 1216 G., Rose, M.T., Rosenberg, J., Sparks, R. and H. Sugano, "A 1217 Common Profile for Instant Messaging (CPIM)", draft-thenine-im- 1218 common-00 (work in progress), August 2000. 1220 [15] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant 1221 Messaging / Presence Protocol Requirements", RFC 2779, February 1222 2000. 1224 [16] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word 1225 Extensions: Character Sets, Languages, and Continuations", RFC 1226 2231, November 1997. 1228 [18] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1229 Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- 1230 HTTP/1.1", RFC 2616, June 1999. 1232 [20] Freed, N., and J. Postel, "IANA Charset Registration 1233 Procedures", BCP 19, RFC 2278, January 1998. 1235 12. AUTHORS' ADDRESSES 1237 Derek Atkins 1238 IHTFP Consulting 1239 6 Farragut Ave 1240 Somerville, MA 02144 1241 USA. 1242 Telephone: +1 617 623 3745 1243 E-mail: derek@ihtfp.com 1244 E-mail: warlord@alum.mit.edu 1246 Graham Klyne 1247 Nine by Nine 1248 14 Chambrai Close 1249 Appleford 1250 Abingdon 1251 OX14 4NT 1252 UK 1253 Telephone: +44 1235 848491 1254 E-mail: GK-IETF@ninebynine.org 1256 Appendix A: Amendment history 1258 [[[RFC editor: please remove this appendix on publication.]]] 1260 00a 01-Feb-2001 Memo initially created. 1262 00b 06-Feb-2001 Editorial review. Reworked namespace framework 1263 description. Deferred specification of mandatory 1264 headers to the application specification, allowing 1265 this document to be less application-dependent. 1266 Expanded references. Replaced some text with ABNF 1267 syntax descriptions. Reordered some major sections. 1269 00c 07-Feb-2001 Folded in some review comments. Fix up some syntax 1270 problems. Other small editorial changes. Add some 1271 references. 1273 01a 29-Mar-2001 Incorporate review comments. State (simply) that 1274 this is a canonical end-to-end format for the purpose 1275 of signature calculation. Defined escape mechanism 1276 for control characters. Header name parameters 1277 placed after the ":". Changed name of Date: header 1278 to DateTime:. Revised syntax to separate character- 1279 level syntax from UTF-8 octet- level syntax. 1281 01b 30-Mar-2001 State explicitly that unrecognized header names 1282 should be ignored. Remove text about 1283 (non)significance of header order: simply say that 1284 order must be preserved. 1286 02a 30-May-2001 Updated reference to date/time draft. Editorial 1287 changes. 1289 03a 13-Jun-2001 Tighten up application of escape sequences. 1291 04a 05-Nov-2001 Add registration templates for Message/CPIM content 1292 type, and urn:ietf:params:cpim-headers: URN space. 1293 Update namespace identifier. Revised application 1294 design considerations to indicate that a default 1295 namespace URI and any implicit prefixes are to be 1296 specified by the MIME media type specification. 1297 Noted variation of ABNF usage from RFC 2234 (exact 1298 case only). Add reference to URN syntax (RFC 2141). 1300 05a 06-Nov-2001 Fix typos. Complete change of 'Date:' header to 1301 'DateTime:'. Updated author affiliations. Fix up 1302 multipart/signed example. 1304 05b 31-Dec-2001 Various editorial changes in response to last-call 1305 comments: more consistent reference to RFC2822/MIME 1306 message format; slightly expanded comment on problems 1307 with X-headers; softened wording about use of Java 1308 escape mechanism to make it clearer that Java is not 1309 a normative reference here; revised phrasing of first 1310 paragraph of section 3; correct other typos. 1312 06a 20-Feb-2002 Fix definition in section 3.6 of NAMECHAR characters 1313 to include apostrophe 0x27 (following RFC 2822). Fix 1314 error in sect 3.1 definition of SEPARATORS. 1316 07a 28-Aug-2002 Fix description of 'require' header in section 4.7. 1318 07b 16-Oct-2002 Change author affiliation details. Update document 1319 and expiry dates, for re-realease of I-D. Update 1320 date-time reference to RFC3339. 1322 08a 09-Jan-2003 Change author affiliation and email details. Update 1323 document and expiry dates, for re-realease of I-D 1324 post-last-call. Separate normative and informative 1325 references. 1327 TODO: 1329 o Replace XXXX with assigned RFC numbers. (Note that this memo 1330 depends on [22] progressing to RFC status.) 1332 o Update references to other CPIM documents. 1334 o Delete reference [14]? 1336 o Renumber references? 1338 REVIEW CHECKLIST: 1340 (Points to be checked or considered more widely on or before final 1341 review.) 1343 o The desirability of a completely rigid syntax. 1345 o Escape mechanism details. 1347 o Check references. 1349 Full copyright statement 1351 Copyright (C) The Internet Society 2002. All Rights Reserved. This 1352 document and translations of it may be copied and furnished to 1353 others, and derivative works that comment on or otherwise explain it 1354 or assist in its implementation may be prepared, copied, published 1355 and distributed, in whole or in part, without restriction of any 1356 kind, provided that the above copyright notice and this paragraph are 1357 included on all such copies and derivative works. 1359 However, this document itself may not be modified in any way, such as 1360 by removing the copyright notice or references to the Internet 1361 Society or other Internet organizations, except as needed for the 1362 purpose of developing Internet standards in which case the procedures 1363 for copyrights defined in the Internet Standards process must be 1364 followed, or as required to translate it into languages other than 1365 English. 1367 The limited permissions granted above are perpetual and will not be 1368 revoked by the Internet Society or its successors or assigns. This 1369 document and the information contained herein is provided on an "AS 1370 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1371 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1372 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1373 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1374 OR FITNESS FOR A PARTICULAR PURPOSE.