idnits 2.17.1 draft-ietf-mhtml-related-v2-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** 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 1 longer page, the longest (page 1) being 438 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 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 (October 1998) is 9325 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'CID' is defined on line 406, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Experimental RFC: RFC 1873 (ref. 'CID') ** Downref: Normative reference to an Informational RFC: RFC 1524 (ref. 'CFG') Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Levinson 2 Internet Draft October 1998 3 draft-ietf-mhtml-related-v2-01.txt Expires: February 1999 4 IETF status to be: Proposed standard 5 Replaces: RFC 2112 7 The MIME Multipart/Related Content-type 9 This draft document is being circulated for comment. Please send 10 your comments to the authors or to the mimesgml mail list 11 mhtml@segate.sunet.se. 13 Status of this Memo 15 This document is an Internet Draft; Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF) its Areas, 17 and Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. They may be updated, replaced, or obsoleted by other 22 documents at any time. It is not appropriate to use Internet Drafts 23 as reference material or to cite them other than as a "working draft" 24 or "work in progress". 26 Please check the abstract listing in each Internet Draft directory 27 for the current status of this or any other Internet Draft. 29 Abstract 31 The Multipart/Related content-type provides a common mechanism for 32 representing objects that are aggregates of related MIME body parts. 33 This document defines the Multipart/Related content-type and provides 34 examples of its use. 36 0. Changes from previous draft 38 Changes from RFC 2112: Corrected cid urls to conform to RFC 2111; 39 the angle brackets were removed. 41 Changes from draft-ietf-mhtml-related-02.txt 43 ....Added mandatory quoting on the type parameter, since it contains 44 special characters ("@") and since MIME (RFC 2045) requires quoting 45 of all parameters to Content-Type which contain special characters. 46 Updated references. 48 0.1 Changes from v2-00 50 Added mandatory quoting for the same reason as above to the start 51 parameter and the cid-list in the start-info parameter. 53 Corrected the syntax for cid-list by making cid-list token on the 54 rhs options (enclosed in square brackets). 56 1. Introduction 58 Several applications of MIME, including MIME-PEM, and MIME-Macintosh 59 and other proposals, require multiple body parts that make sense only 60 in the aggregate. The present approach to these compound objects has 61 been to define specific multipart subtypes for each new object. In 62 keeping with the MIME philosophy of having one mechanism to achieve 63 the same goal for different purposes, this document describes a 64 single mechanism for such aggregate or compound objects. 66 The Multipart/Related content-type addresses the MIME representation 67 of compound objects. The object is categorized by a "type" 68 parameter. Additional parameters are provided to indicate a specific 69 starting body part or root and auxiliary information which may be 70 required when unpacking or processing the object. 72 Multipart/Related MIME entities may contain Content-Disposition 73 headers that provide suggestions for the storage and display of a 74 body part. Multipart/Related processing takes precedence over 75 Content-Disposition; the interaction between them is discussed in 76 section 4. 78 Responsibility for the display or processing of a Multipart/Related's 79 constituent entities rests with the application that handles the 80 compound object. 82 2. Multipart/Related Registration Information 84 The following form is copied from RFC 1590, Appendix A. 86 To: IANA@isi.edu 87 Subject: Registration of new Media Type content-type/subtype 89 Media Type name: Multipart 91 Media subtype name: Related 93 Required parameters: Type, a media type/subtype. 95 Optional parameters: Start 96 Start-info 98 Encoding considerations: Multipart content-types cannot have 99 encodings. 101 Security considerations: Depends solely on the referenced type. 103 Published specification: RFC-REL (this document). 105 Person & email address to contact for further information: 106 Edward Levinson 107 47 Clive Street 108 Metuchen, NJ 08840-1060 109 +1 908 494 1606 110 XIson@cnj.digex.net 112 3. Intended usage 114 The Multipart/Related media type is intended for compound objects 115 consisting of several inter-related body parts. For a 116 Multipart/Related object, proper display cannot be achieved by 117 individually displaying the constituent body parts. The content-type 118 of the Multipart/Related object is specified by the type parameter. 119 The "start" parameter, if given, points, via a content-ID, to the 120 body part that contains the object root. The default root is the 121 first body part within the Multipart/Related body. 123 The relationships among the body parts of a compound object 124 distinguishes it from other object types. These relationships are 125 often represented by links internal to the object's components that 126 reference the other components. Within a single operating 127 environment the links are often file names, such links may be 128 represented within a MIME message using content-IDs or the value of 129 some other "Content-" headers. 131 3.1. The Type Parameter 133 The type parameter must be specified and its value is the MIME media 134 type of the "root" body part. It permits a MIME user agent to 135 determine the content-type without reference to the enclosed body 136 part. If the value of the type parameter and the root body part's 137 content-type differ then the User Agent's behavior is undefined. 139 3.2. The Start Parameter 141 The start parameter, if given, is the content-ID of the compound 142 object's "root". If not present the "root" is the first body part in 143 the Multipart/Related entity. The "root" is the element the 144 applications processes first. 146 3.3. The Start-Info Parameter 148 Additional information can be provided to an application by the 149 start-info parameter. It contains either a string or points, via a 150 content-ID, to another MIME entity in the message. A typical use 151 might be to provide additional command line parameters or a MIME 152 entity giving auxiliary information for processing the compound 153 object. 155 Applications that use Multipart/Related must specify the 156 interpretation of start-info. User Agents shall provide the 157 parameter's value to the processing application. Processes can 158 distinguish a start-info reference from a token or quoted-string by 159 examining the first non-white-space character, "<" indicates a 160 reference. 162 3.4. Syntax 164 related-param := [ ";" "start" "=" <"> cid <"> ] 165 [ ";" "start-info" "=" 166 ( <"> cid-list <"> / value ) ] 167 [ ";" "type" "=" <"> type "/" subtype <"> ] 168 ; order independent 170 cid-list := cid [ cid-list ] 172 cid := msg-id ; c.f. [822] 174 value := token / quoted-string ; c.f. [MIME] 175 ; value cannot begin with "<" 177 Note that the parameter values will usually require quoting. Msg-id 178 contains the special characters "<", ">", "@", and perhaps other 179 special characters. If msg-id contains quoted-strings, those quote 180 marks must be escaped. Similarly, the type parameter contains the 181 special character "/". The syntax include the required quoting. 183 4. Handling Content-Disposition Headers 185 Content-Disposition Headers [DISP] suggest presentation styles for 186 MIME body parts. [DISP] describes two presentation styles, called 187 the disposition type, INLINE and ATTACHMENT. These, used within a 188 multipart entity, allow the sender to suggest presentation 189 information. [DISP] also provides for an optional storage (file) 190 name. Content-Disposition headers could appear in one or more body 191 parts contained within a Multipart/Related entity. 193 Using Content-Disposition headers in addition to Multipart/Related 194 provides presentation information to User Agents that do not 195 recognize Multipart/Related. They will treat the multipart as 196 Multipart/Mixed and they may find the Content-Disposition information 197 useful. 199 With Multipart/Related however, the application processing the 200 compound object determines the presentation style for all the 201 contained parts. In that context the Content-Disposition header 202 information is redundant or even misleading. Hence, User Agents that 203 understand Multipart/Related shall ignore the disposition type within 204 a Multipart/Related body part. 206 It may be possible for a User Agent capable of handling both 207 Multipart/Related and Content-Disposition headers to provide the 208 invoked application the Content-Disposition header's optional 209 filename parameter to the Multipart/Related. The use of that 210 information will depend on the specific application and should be 211 specified when describing the handling of the corresponding compound 212 object. Such descriptions would be appropriate in an RFC registering 213 that object's media type. 215 5. Examples 217 5.1 Application/X-FixedRecord 219 The X-FixedRecord content-type consists of one or more octet-streams 220 and a list of the lengths of each record. The root, which lists the 221 record lengths of each record within the streams. The record length 222 list, type Application/X-FixedRecord, consists of a set of INTEGERs 223 in ASCII format, one per line. Each INTEGER gives the number of 224 octets from the octet-stream body part that constitute the next 225 "record". 227 The example below, uses a single data block. 229 Content-Type: Multipart/Related; boundary=example-1 230 start="<950120.aaCC@XIson.com>"; 231 type="Application/X-FixedRecord" 232 start-info="-o ps" 234 --example-1 235 Content-Type: Application/X-FixedRecord 236 Content-ID: <950120.aaCC@XIson.com> 238 25 239 10 240 34 241 10 242 25 243 21 244 26 245 10 246 --example-1 247 Content-Type: Application/octet-stream 248 Content-Description: The fixed length records 249 Content-Transfer-Encoding: base64 250 Content-ID: <950120.aaCB@XIson.com> 252 T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS 253 BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk 254 IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS 255 BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1 256 YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW 257 NrIHF1YWNrCkUgSSBFIEkgTwo= 259 --example-1-- 261 5.2 Text/X-Okie 263 The Text/X-Okie is an invented markup language permitting the 264 inclusion of images with text. A feature of this example is the 265 inclusion of two additional body parts, both picture. They are 266 referred to internally by the encapsulated document via each 267 picture's body part content-ID. Usage of "cid:", as in this example, 268 may be useful for a variety of compound objects. It is not, however, 269 a part of the Multipart/Related specification. 271 Content-Type: Multipart/Related; boundary=example-2; 272 start="<950118.AEBH@XIson.com>" 273 type="Text/x-Okie" 275 --example-2 276 Content-Type: Text/x-Okie; charset=iso-8859-1; 277 declaration="<950118.AEB0@XIson.com>" 278 Content-ID: <950118.AEBH@XIson.com> 279 Content-Description: Document 281 {doc} 282 This picture was taken by an automatic camera mounted ... 283 {image file=cid:950118.AECB@XIson.com} 284 {para} 285 Now this is an enlargement of the area ... 286 {image file=cid:950118:AFDH@XIson.com} 287 {/doc} 288 --example-2 289 Content-Type: image/jpeg 290 Content-ID: <950118.AFDH@XIson.com> 291 Content-Transfer-Encoding: BASE64 292 Content-Description: Picture A 294 [encoded jpeg image] 295 --example-2 296 Content-Type: image/jpeg 297 Content-ID: <950118.AECB@XIson.com> 298 Content-Transfer-Encoding: BASE64 299 Content-Description: Picture B 301 [encoded jpeg image] 302 --example-2-- 304 5.3 Content-Disposition 306 In the above example each image body part could also have a Content- 307 Disposition header. For example, 309 ... 310 --example-2 311 Content-Type: image/jpeg 312 Content-ID: <950118.AECB@XIson.com> 313 Content-Transfer-Encoding: BASE64 314 Content-Description: Picture B 315 Content-Disposition: INLINE 317 [encoded jpeg image] 318 --example-2-- 320 User Agents that recognize Multipart/Related will ignore the Content- 321 Disposition header's disposition type. Other User Agents will 322 process the Multipart/Related as Multipart/Mixed and may make use of 323 that header's information. 325 6. User Agent Requirements 327 User agents that do not recognize Multipart/Related shall, in 328 accordance with [MIME], treat the entire entity as Multipart/Mixed. 329 MIME User Agents that do recognize Multipart/Related entities but are 330 unable to process the given type should give the user the option of 331 suppressing the entire Multipart/Related body part shall be. 333 Existing MIME-capable mail user agents (MUAs) handle the existing 334 media types in a straightforward manner. For discrete media types 335 (e.g. text, image, etc.) the body of the entity can be directly 336 passed to a display process. Similarly the existing composite 337 subtypes can be reduced to handing one or more discrete types. 338 Handling Multipart/Related differs in that processing cannot be 339 reduced to handling the individual entities. 341 The following sections discuss what information the processing 342 application requires. 344 It is possible that an application specific "receiving agent" will 345 manipulate the entities for display prior to invoking actual 346 application process. Okie, above, is an example of this; it may need 347 a receiving agent to parse the document and substitute local file 348 names for the originator's file names. Other applications may just 349 require a table showing the correspondence between the local file 350 names and the originator's. The receiving agent takes responsibility 351 for such processing. 353 6.1 Data Requirements 355 MIME-capable mail user agents (MUAs) are required to provide the 356 application: 358 (a) the bodies of the MIME entities and the entity Content-* headers, 360 (b) the parameters of the Multipart/Related Content-type header, and 362 (c) the correspondence between each body's local file name, that 363 body's header data, and, if present, the body part's content-ID. 365 6.2 Storing Multipart/Related Entities 367 The Multipart/Related media type will be used for objects that have 368 internal linkages between the body parts. When the objects are 369 stored the linkages may require processing by the application or its 370 receiving agent. 372 6.3 Recursion 374 MIME is a recursive structure. Hence one must expect a Multi- 375 part/Related entity to contain other Multipart/Related entities. 376 When a Multipart/Related entity is being processed for display or 377 storage, any enclosed Multipart/Related entities shall be processed 378 as though they were being stored. 380 6.4 Configuration Considerations 382 It is suggested that MUAs that use configuration mechanisms, see 383 [CFG] for an example, refer to Multipart/Related as Multi- 384 part/Related/, were is the value of the "type" parame- 385 ter. 387 7. Security considerations 389 Security considerations relevant to Multipart/Related are identical 390 to those of the underlying content-type. 392 8. Acknowledgments 394 This proposal is the result of conversations the author has had with 395 many people. In particular, Harald A. Alvestrand, James Clark, 396 Charles Goldfarb, Gary Houston, Ned Freed, Ray Moody, and Don Stinch- 397 field, provided both encouragement and invaluable help. The author, 398 however, take full responsibility for all errors contained in this 399 document. 401 9. References 403 [822] Crocker, D., "Standard for the Format of ARPA Internet Text 404 Messages", August 1982, University of Delaware, RFC 822. 406 [CID] E. Levinson, J. Clark, "Message/External-Body Content-ID 407 Access Type", 12/26/1995, RFC 1873 Levinson, E., "Mes- 408 sage/External-Body Content-ID Access Type", work in 409 progress, ftp://ds.internic.net/internet-drafts/draft-ietf- 410 mimesgml-access-cid-01.txt. 412 [CFG] Borenstein, N., "A User Agent Configuration Mechanism For 413 Multimedia Mail Format Information", September 23, 1993, RFC 414 1524 416 [DISP] R. Troost, S. Dorner, "Communicating Presentation Informa- 417 tion in Internet Messages: The Content-Disposition Header", 418 August 1997, RFC 2183. 420 [MIME] Freed, N., Borenstein, N.: Multipurpose Internet Mail 421 Extensions (MIME) Part One: Format of Internet Message 422 Bodies. November 1996, RFC 2045. 424 9. Author's addresses 426 Edward Levinson 427 47 Clive Street 428 Metuchen, NJ 08840-1060 429 USA 430 Phone: +1 908 494 1606 431 E-mail: XIson@cnj.digex.com