rfc2387.txt (18864B)
1 2 3 4 5 6 7 Network Working Group E. Levinson 8 Request for Comments: 2387 August 1998 9 Obsoletes: 2112 10 Category: Standards Track 11 12 13 The MIME Multipart/Related Content-type 14 15 Status of this Memo 16 17 This document specifies an Internet standards track protocol for the 18 Internet community, and requests discussion and suggestions for 19 improvements. Please refer to the current edition of the "Internet 20 Official Protocol Standards" (STD 1) for the standardization state 21 and status of this protocol. Distribution of this memo is unlimited. 22 23 Copyright Notice 24 25 Copyright (C) The Internet Society (1998). All Rights Reserved. 26 27 Abstract 28 29 The Multipart/Related content-type provides a common mechanism for 30 representing objects that are aggregates of related MIME body parts. 31 This document defines the Multipart/Related content-type and provides 32 examples of its use. 33 34 1. Introduction 35 36 Several applications of MIME, including MIME-PEM, and MIME-Macintosh 37 and other proposals, require multiple body parts that make sense only 38 in the aggregate. The present approach to these compound objects has 39 been to define specific multipart subtypes for each new object. In 40 keeping with the MIME philosophy of having one mechanism to achieve 41 the same goal for different purposes, this document describes a 42 single mechanism for such aggregate or compound objects. 43 44 The Multipart/Related content-type addresses the MIME representation 45 of compound objects. The object is categorized by a "type" 46 parameter. Additional parameters are provided to indicate a specific 47 starting body part or root and auxiliary information which may be 48 required when unpacking or processing the object. 49 50 Multipart/Related MIME entities may contain Content-Disposition 51 headers that provide suggestions for the storage and display of a 52 body part. Multipart/Related processing takes precedence over 53 Content-Disposition; the interaction between them is discussed in 54 section 4. 55 56 57 58 Levinson Standards Track [Page 1] 59 60 RFC 2387 Multipart/Related August 1998 61 62 63 Responsibility for the display or processing of a Multipart/Related's 64 constituent entities rests with the application that handles the 65 compound object. 66 67 2. Multipart/Related Registration Information 68 69 The following form is copied from RFC 1590, Appendix A. 70 71 To: IANA@isi.edu 72 Subject: Registration of new Media Type content-type/subtype 73 74 Media Type name: Multipart 75 76 Media subtype name: Related 77 78 Required parameters: Type, a media type/subtype. 79 80 Optional parameters: Start 81 Start-info 82 83 Encoding considerations: Multipart content-types cannot have 84 encodings. 85 86 Security considerations: Depends solely on the referenced type. 87 88 Published specification: RFC-REL (this document). 89 90 Person & email address to contact for further information: 91 Edward Levinson 92 47 Clive Street 93 Metuchen, NJ 08840-1060 94 +1 908 494 1606 95 XIson@cnj.digex.net 96 97 3. Intended usage 98 99 The Multipart/Related media type is intended for compound objects 100 consisting of several inter-related body parts. For a 101 Multipart/Related object, proper display cannot be achieved by 102 individually displaying the constituent body parts. The content-type 103 of the Multipart/Related object is specified by the type parameter. 104 The "start" parameter, if given, points, via a content-ID, to the 105 body part that contains the object root. The default root is the 106 first body part within the Multipart/Related body. 107 108 The relationships among the body parts of a compound object 109 distinguishes it from other object types. These relationships are 110 often represented by links internal to the object's components that 111 112 113 114 Levinson Standards Track [Page 2] 115 116 RFC 2387 Multipart/Related August 1998 117 118 119 reference the other components. Within a single operating 120 environment the links are often file names, such links may be 121 represented within a MIME message using content-IDs or the value of 122 some other "Content-" headers. 123 124 3.1. The Type Parameter 125 126 The type parameter must be specified and its value is the MIME media 127 type of the "root" body part. It permits a MIME user agent to 128 determine the content-type without reference to the enclosed body 129 part. If the value of the type parameter and the root body part's 130 content-type differ then the User Agent's behavior is undefined. 131 132 3.2. The Start Parameter 133 134 The start parameter, if given, is the content-ID of the compound 135 object's "root". If not present the "root" is the first body part in 136 the Multipart/Related entity. The "root" is the element the 137 applications processes first. 138 139 3.3. The Start-Info Parameter 140 141 Additional information can be provided to an application by the 142 start-info parameter. It contains either a string or points, via a 143 content-ID, to another MIME entity in the message. A typical use 144 might be to provide additional command line parameters or a MIME 145 entity giving auxiliary information for processing the compound 146 object. 147 148 Applications that use Multipart/Related must specify the 149 interpretation of start-info. User Agents shall provide the 150 parameter's value to the processing application. Processes can 151 distinguish a start-info reference from a token or quoted-string by 152 examining the first non-white-space character, "<" indicates a 153 reference. 154 155 3.4. Syntax 156 157 related-param := [ ";" "start" "=" cid ] 158 [ ";" "start-info" "=" 159 ( cid-list / value ) ] 160 [ ";" "type" "=" type "/" subtype ] 161 ; order independent 162 163 cid-list := cid cid-list 164 165 cid := msg-id ; c.f. [822] 166 167 168 169 170 Levinson Standards Track [Page 3] 171 172 RFC 2387 Multipart/Related August 1998 173 174 175 value := token / quoted-string ; c.f. [MIME] 176 ; value cannot begin with "<" 177 178 Note that the parameter values will usually require quoting. Msg-id 179 contains the special characters "<", ">", "@", and perhaps other 180 special characters. If msg-id contains quoted-strings, those quote 181 marks must be escaped. Similarly, the type parameter contains the 182 special character "/". 183 184 4. Handling Content-Disposition Headers 185 186 Content-Disposition Headers [DISP] suggest presentation styles for 187 MIME body parts. [DISP] describes two presentation styles, called 188 the disposition type, INLINE and ATTACHMENT. These, used within a 189 multipart entity, allow the sender to suggest presentation 190 information. [DISP] also provides for an optional storage (file) 191 name. Content-Disposition headers could appear in one or more body 192 parts contained within a Multipart/Related entity. 193 194 Using Content-Disposition headers in addition to Multipart/Related 195 provides presentation information to User Agents that do not 196 recognize Multipart/Related. They will treat the multipart as 197 Multipart/Mixed and they may find the Content-Disposition information 198 useful. 199 200 With Multipart/Related however, the application processing the 201 compound object determines the presentation style for all the 202 contained parts. In that context the Content-Disposition header 203 information is redundant or even misleading. Hence, User Agents that 204 understand Multipart/Related shall ignore the disposition type within 205 a Multipart/Related body part. 206 207 It may be possible for a User Agent capable of handling both 208 Multipart/Related and Content-Disposition headers to provide the 209 invoked application the Content-Disposition header's optional 210 filename parameter to the Multipart/Related. The use of that 211 information will depend on the specific application and should be 212 specified when describing the handling of the corresponding compound 213 object. Such descriptions would be appropriate in an RFC registering 214 that object's media type. 215 216 5. Examples 217 218 5.1 Application/X-FixedRecord 219 220 The X-FixedRecord content-type consists of one or more octet-streams 221 and a list of the lengths of each record. The root, which lists the 222 record lengths of each record within the streams. The record length 223 224 225 226 Levinson Standards Track [Page 4] 227 228 RFC 2387 Multipart/Related August 1998 229 230 231 list, type Application/X-FixedRecord, consists of a set of INTEGERs 232 in ASCII format, one per line. Each INTEGER gives the number of 233 octets from the octet-stream body part that constitute the next 234 "record". 235 236 The example below, uses a single data block. 237 238 Content-Type: Multipart/Related; boundary=example-1 239 start="<950120.aaCC@XIson.com>"; 240 type="Application/X-FixedRecord" 241 start-info="-o ps" 242 243 --example-1 244 Content-Type: Application/X-FixedRecord 245 Content-ID: <950120.aaCC@XIson.com> 246 247 25 248 10 249 34 250 10 251 25 252 21 253 26 254 10 255 --example-1 256 Content-Type: Application/octet-stream 257 Content-Description: The fixed length records 258 Content-Transfer-Encoding: base64 259 Content-ID: <950120.aaCB@XIson.com> 260 261 T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS 262 BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk 263 IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS 264 BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1 265 YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW 266 NrIHF1YWNrCkUgSSBFIEkgTwo= 267 268 --example-1-- 269 270 271 272 273 274 275 276 277 278 279 280 281 282 Levinson Standards Track [Page 5] 283 284 RFC 2387 Multipart/Related August 1998 285 286 287 5.2 Text/X-Okie 288 289 The Text/X-Okie is an invented markup language permitting the 290 inclusion of images with text. A feature of this example is the 291 inclusion of two additional body parts, both picture. They are 292 referred to internally by the encapsulated document via each 293 picture's body part content-ID. Usage of "cid:", as in this example, 294 may be useful for a variety of compound objects. It is not, however, 295 a part of the Multipart/Related specification. 296 297 Content-Type: Multipart/Related; boundary=example-2; 298 start="<950118.AEBH@XIson.com>" 299 type="Text/x-Okie" 300 301 --example-2 302 Content-Type: Text/x-Okie; charset=iso-8859-1; 303 declaration="<950118.AEB0@XIson.com>" 304 Content-ID: <950118.AEBH@XIson.com> 305 Content-Description: Document 306 307 {doc} 308 This picture was taken by an automatic camera mounted ... 309 {image file=cid:950118.AECB@XIson.com} 310 {para} 311 Now this is an enlargement of the area ... 312 {image file=cid:950118:AFDH@XIson.com} 313 {/doc} 314 --example-2 315 Content-Type: image/jpeg 316 Content-ID: <950118.AFDH@XIson.com> 317 Content-Transfer-Encoding: BASE64 318 Content-Description: Picture A 319 320 [encoded jpeg image] 321 --example-2 322 Content-Type: image/jpeg 323 Content-ID: <950118.AECB@XIson.com> 324 Content-Transfer-Encoding: BASE64 325 Content-Description: Picture B 326 327 [encoded jpeg image] 328 --example-2-- 329 330 5.3 Content-Disposition 331 332 In the above example each image body part could also have a Content- 333 Disposition header. For example, 334 335 336 337 338 Levinson Standards Track [Page 6] 339 340 RFC 2387 Multipart/Related August 1998 341 342 343 --example-2 344 Content-Type: image/jpeg 345 Content-ID: <950118.AECB@XIson.com> 346 Content-Transfer-Encoding: BASE64 347 Content-Description: Picture B 348 Content-Disposition: INLINE 349 350 [encoded jpeg image] 351 --example-2-- 352 353 User Agents that recognize Multipart/Related will ignore the 354 Content-Disposition header's disposition type. Other User Agents 355 will process the Multipart/Related as Multipart/Mixed and may make 356 use of that header's information. 357 358 6. User Agent Requirements 359 360 User agents that do not recognize Multipart/Related shall, in 361 accordance with [MIME], treat the entire entity as Multipart/Mixed. 362 MIME User Agents that do recognize Multipart/Related entities but are 363 unable to process the given type should give the user the option of 364 suppressing the entire Multipart/Related body part shall be. 365 366 Existing MIME-capable mail user agents (MUAs) handle the existing 367 media types in a straightforward manner. For discrete media types 368 (e.g. text, image, etc.) the body of the entity can be directly 369 passed to a display process. Similarly the existing composite 370 subtypes can be reduced to handing one or more discrete types. 371 Handling Multipart/Related differs in that processing cannot be 372 reduced to handling the individual entities. 373 374 The following sections discuss what information the processing 375 application requires. 376 377 It is possible that an application specific "receiving agent" will 378 manipulate the entities for display prior to invoking actual 379 application process. Okie, above, is an example of this; it may need 380 a receiving agent to parse the document and substitute local file 381 names for the originator's file names. Other applications may just 382 require a table showing the correspondence between the local file 383 names and the originator's. The receiving agent takes responsibility 384 for such processing. 385 386 6.1 Data Requirements 387 388 MIME-capable mail user agents (MUAs) are required to provide the 389 application: 390 391 392 393 394 Levinson Standards Track [Page 7] 395 396 RFC 2387 Multipart/Related August 1998 397 398 399 (a) the bodies of the MIME entities and the entity Content-* headers, 400 401 (b) the parameters of the Multipart/Related Content-type header, and 402 403 (c) the correspondence between each body's local file name, that 404 body's header data, and, if present, the body part's content-ID. 405 406 6.2 Storing Multipart/Related Entities 407 408 The Multipart/Related media type will be used for objects that have 409 internal linkages between the body parts. When the objects are 410 stored the linkages may require processing by the application or its 411 receiving agent. 412 413 6.3 Recursion 414 415 MIME is a recursive structure. Hence one must expect a 416 Multipart/Related entity to contain other Multipart/Related entities. 417 When a Multipart/Related entity is being processed for display or 418 storage, any enclosed Multipart/Related entities shall be processed 419 as though they were being stored. 420 421 6.4 Configuration Considerations 422 423 It is suggested that MUAs that use configuration mechanisms, see 424 [CFG] for an example, refer to Multipart/Related as Multi- 425 part/Related/<type>, were <type> is the value of the "type" 426 parameter. 427 428 7. Security Considerations 429 430 Security considerations relevant to Multipart/Related are identical 431 to those of the underlying content-type. 432 433 8. Acknowledgments 434 435 This proposal is the result of conversations the author has had with 436 many people. In particular, Harald A. Alvestrand, James Clark, 437 Charles Goldfarb, Gary Houston, Ned Freed, Ray Moody, and Don 438 Stinchfield, provided both encouragement and invaluable help. The 439 author, however, take full responsibility for all errors contained in 440 this document. 441 442 443 444 445 446 447 448 449 450 Levinson Standards Track [Page 8] 451 452 RFC 2387 Multipart/Related August 1998 453 454 455 9. References 456 457 [822] Crocker, D., "Standard for the Format of ARPA Internet 458 Text Messages", STD 11, RFC 822, August 1982. 459 460 [CID] Levinson, E., and J. Clark, "Message/External-Body 461 Content-ID Access Type", RFC 1873, December 1995, 462 Levinson, E., "Message/External-Body Content-ID Access 463 Type", Work in Progress. 464 465 [CFG] Borenstein, N., "A User Agent Configuration Mechanism For 466 Multimedia Mail Format Information", RFC 1524, September 467 1993. 468 469 [DISP] Troost, R., and S. Dorner, "Communicating Presentation 470 Information in Internet Messages: The Content- 471 Disposition Header", RFC 1806, June 1995. 472 473 [MIME] Borenstein, N., and Freed, N., "Multipurpose Internet 474 Mail Extensions (MIME) Part One: Format of Internet 475 Message Bodies", RFC 2045, November 1996. 476 477 9. Author's Address 478 479 Edward Levinson 480 47 Clive Street 481 Metuchen, NJ 08840-1060 482 USA 483 484 Phone: +1 908 494 1606 485 EMail: XIson@cnj.digex.com 486 487 10. Changes from previous draft (RFC 2112) 488 489 Corrected cid urls to conform to RFC 2111; the angle brackets were 490 removed. 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 Levinson Standards Track [Page 9] 507 508 RFC 2387 Multipart/Related August 1998 509 510 511 11. Full Copyright Statement 512 513 Copyright (C) The Internet Society (1998). All Rights Reserved. 514 515 This document and translations of it may be copied and furnished to 516 others, and derivative works that comment on or otherwise explain it 517 or assist in its implementation may be prepared, copied, published 518 and distributed, in whole or in part, without restriction of any 519 kind, provided that the above copyright notice and this paragraph are 520 included on all such copies and derivative works. However, this 521 document itself may not be modified in any way, such as by removing 522 the copyright notice or references to the Internet Society or other 523 Internet organizations, except as needed for the purpose of 524 developing Internet standards in which case the procedures for 525 copyrights defined in the Internet Standards process must be 526 followed, or as required to translate it into languages other than 527 English. 528 529 The limited permissions granted above are perpetual and will not be 530 revoked by the Internet Society or its successors or assigns. 531 532 This document and the information contained herein is provided on an 533 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 534 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 535 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 536 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 537 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 Levinson Standards Track [Page 10] 563