idnits 2.17.1 draft-ietf-mhtml-rel-v2-00.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-24) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 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 (September 1997) is 9718 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 386, 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') ** Obsolete normative reference: RFC 1806 (ref. 'DISP') (Obsoleted by RFC 2183) ** Obsolete normative reference: RFC 1341 (ref. 'MIME') (Obsoleted by RFC 1521) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIMEHTML Working Group E. Levinson 2 draft-ietf-mhtml-rel-v2-00.txt 3 IETF Status: To replace RFC 2112 as a new Proposed Standard 4 Expires: March 1998 September 1997 6 The MIME Multipart/Related Content-type 8 This draft document is being circulated for comment. Please send 9 your comments to the authors or to the mimesgml mail list 10 mhtml@segate.sunet.se. 12 Status of this Memo 14 This document is an Internet Draft; Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF) its Areas, 16 and Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. They may be updated, replaced, or obsoleted by other 21 documents at any time. It is not appropriate to use Internet Drafts 22 as reference material or to cite them other than as a "working draft" 23 or "work in progress". 25 Please check the abstract listing in each Internet Draft directory 26 for the current status of this or any other Internet Draft. 28 Abstract 30 The Multipart/Related content-type provides a common mechanism for 31 representing objects that are aggregates of related MIME body parts. 32 This document defines the Multipart/Related content-type and provides 33 examples of its use. 35 0. Changes from previous draft (RFC 2112) 37 Corrected cid urls to conform to RFC 2111; the angle brackets were 38 removed. 40 1. Introduction 42 Several applications of MIME, including MIME-PEM, and MIME-Macintosh 43 and other proposals, require multiple body parts that make sense only 44 in the aggregate. The present approach to these compound objects has 45 been to define specific multipart subtypes for each new object. In 46 keeping with the MIME philosophy of having one mechanism to achieve 47 the same goal for different purposes, this document describes a 48 single mechanism for such aggregate or compound objects. 50 The Multipart/Related content-type addresses the MIME representation 51 of compound objects. The object is categorized by a "type" 52 parameter. Additional parameters are provided to indicate a specific 53 starting body part or root and auxiliary information which may be 54 required when unpacking or processing the object. 56 Multipart/Related MIME entities may contain Content-Disposition 57 headers that provide suggestions for the storage and display of a 58 body part. Multipart/Related processing takes precedence over 59 Content-Disposition; the interaction between them is discussed in 60 section 4. 62 Responsibility for the display or processing of a Multipart/Related's 63 constituent entities rests with the application that handles the 64 compound object. 66 2. Multipart/Related Registration Information 68 The following form is copied from RFC 1590, Appendix A. 70 To: IANA@isi.edu 71 Subject: Registration of new Media Type content-type/subtype 73 Media Type name: Multipart 75 Media subtype name: Related 77 Required parameters: Type, a media type/subtype. 79 Optional parameters: Start 80 Start-info 82 Encoding considerations: Multipart content-types cannot have 83 encodings. 85 Security considerations: Depends solely on the referenced type. 87 Published specification: RFC-REL (this document). 89 Person & email address to contact for further information: 90 Edward Levinson 91 47 Clive Street 92 Metuchen, NJ 08840-1060 93 +1 908 494 1606 94 XIson@cnj.digex.net 96 3. Intended usage 97 The Multipart/Related media type is intended for compound objects 98 consisting of several inter-related body parts. For a 99 Multipart/Related object, proper display cannot be achieved by 100 individually displaying the constituent body parts. The content-type 101 of the Multipart/Related object is specified by the type parameter. 102 The "start" parameter, if given, points, via a content-ID, to the 103 body part that contains the object root. The default root is the 104 first body part within the Multipart/Related body. 106 The relationships among the body parts of a compound object 107 distinguishes it from other object types. These relationships are 108 often represented by links internal to the object's components that 109 reference the other components. Within a single operating 110 environment the links are often file names, such links may be 111 represented within a MIME message using content-IDs or the value of 112 some other "Content-" headers. 114 3.1. The Type Parameter 116 The type parameter must be specified and its value is the MIME media 117 type of the "root" body part. It permits a MIME user agent to 118 determine the content-type without reference to the enclosed body 119 part. If the value of the type parameter and the root body part's 120 content-type differ then the User Agent's behavior is undefined. 122 3.2. The Start Parameter 124 The start parameter, if given, is the content-ID of the compound 125 object's "root". If not present the "root" is the first body part in 126 the Multipart/Related entity. The "root" is the element the 127 applications processes first. 129 3.3. The Start-Info Parameter 131 Additional information can be provided to an application by the 132 start-info parameter. It contains either a string or points, via a 133 content-ID, to another MIME entity in the message. A typical use 134 might be to provide additional command line parameters or a MIME 135 entity giving auxiliary information for processing the compound 136 object. 138 Applications that use Multipart/Related must specify the 139 interpretation of start-info. User Agents shall provide the 140 parameter's value to the processing application. Processes can 141 distinguish a start-info reference from a token or quoted-string by 142 examining the first non-white-space character, "<" indicates a 143 reference. 145 3.4. Syntax 147 related-param := [ ";" "start" "=" cid ] 148 [ ";" "start-info" "=" 149 ( cid-list / value ) ] 150 [ ";" "type" "=" type "/" subtype ] 151 ; order independent 153 cid-list := cid cid-list 155 cid := msg-id ; c.f. [822] 157 value := token / quoted-string ; c.f. [MIME] 158 ; value cannot begin with "<" 160 Note that the parameter values will usually require quoting. Msg-id 161 contains the special characters "<", ">", "@", and perhaps other 162 special characters. If msg-id contains quoted-strings, those quote 163 marks must be escaped. Similarly, the type parameter contains the 164 special character "/". 166 4. Handling Content-Disposition Headers 168 Content-Disposition Headers [DISP] suggest presentation styles for 169 MIME body parts. [DISP] describes two presentation styles, called 170 the disposition type, INLINE and ATTACHMENT. These, used within a 171 multipart entity, allow the sender to suggest presentation 172 information. [DISP] also provides for an optional storage (file) 173 name. Content-Disposition headers could appear in one or more body 174 parts contained within a Multipart/Related entity. 176 Using Content-Disposition headers in addition to Multipart/Related 177 provides presentation information to User Agents that do not 178 recognize Multipart/Related. They will treat the multipart as 179 Multipart/Mixed and they may find the Content-Disposition information 180 useful. 182 With Multipart/Related however, the application processing the 183 compound object determines the presentation style for all the 184 contained parts. In that context the Content-Disposition header 185 information is redundant or even misleading. Hence, User Agents that 186 understand Multipart/Related shall ignore the disposition type within 187 a Multipart/Related body part. 189 It may be possible for a User Agent capable of handling both 190 Multipart/Related and Content-Disposition headers to provide the 191 invoked application the Content-Disposition header's optional 192 filename parameter to the Multipart/Related. The use of that 193 information will depend on the specific application and should be 194 specified when describing the handling of the corresponding compound 195 object. Such descriptions would be appropriate in an RFC registering 196 that object's media type. 198 5. Examples 200 5.1 Application/X-FixedRecord 202 The X-FixedRecord content-type consists of one or more octet-streams 203 and a list of the lengths of each record. The root, which lists the 204 record lengths of each record within the streams. The record length 205 list, type Application/X-FixedRecord, consists of a set of INTEGERs 206 in ASCII format, one per line. Each INTEGER gives the number of 207 octets from the octet-stream body part that constitute the next 208 "record". 210 The example below, uses a single data block. 212 Content-Type: Multipart/Related; boundary=example-1 213 start="<950120.aaCC@XIson.com>"; 214 type="Application/X-FixedRecord" 215 start-info="-o ps" 217 --example-1 218 Content-Type: Application/X-FixedRecord 219 Content-ID: <950120.aaCC@XIson.com> 221 25 222 10 223 34 224 10 225 25 226 21 227 26 228 10 229 --example-1 230 Content-Type: Application/octet-stream 231 Content-Description: The fixed length records 232 Content-Transfer-Encoding: base64 233 Content-ID: <950120.aaCB@XIson.com> 235 T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS 236 BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk 237 IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS 238 BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1 239 YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW 240 NrIHF1YWNrCkUgSSBFIEkgTwo= 242 --example-1-- 244 5.2 Text/X-Okie 246 The Text/X-Okie is an invented markup language permitting the 247 inclusion of images with text. A feature of this example is the 248 inclusion of two additional body parts, both picture. They are 249 referred to internally by the encapsulated document via each 250 picture's body part content-ID. Usage of "cid:", as in this example, 251 may be useful for a variety of compound objects. It is not, however, 252 a part of the Multipart/Related specification. 254 Content-Type: Multipart/Related; boundary=example-2; 255 start="<950118.AEBH@XIson.com>" 256 type="Text/x-Okie" 258 --example-2 259 Content-Type: Text/x-Okie; charset=iso-8859-1; 260 declaration="<950118.AEB0@XIson.com>" 261 Content-ID: <950118.AEBH@XIson.com> 262 Content-Description: Document 264 {doc} 265 This picture was taken by an automatic camera mounted ... 266 {image file=cid:950118.AECB@XIson.com} 267 {para} 268 Now this is an enlargement of the area ... 269 {image file=cid:950118:AFDH@XIson.com} 270 {/doc} 271 --example-2 272 Content-Type: image/jpeg 273 Content-ID: <950118.AFDH@XIson.com> 274 Content-Transfer-Encoding: BASE64 275 Content-Description: Picture A 277 [encoded jpeg image] 278 --example-2 279 Content-Type: image/jpeg 280 Content-ID: <950118.AECB@XIson.com> 281 Content-Transfer-Encoding: BASE64 282 Content-Description: Picture B 284 [encoded jpeg image] 285 --example-2-- 287 5.3 Content-Disposition 288 In the above example each image body part could also have a Content- 289 Disposition header. For example, 291 ... 292 --example-2 293 Content-Type: image/jpeg 294 Content-ID: <950118.AECB@XIson.com> 295 Content-Transfer-Encoding: BASE64 296 Content-Description: Picture B 297 Content-Disposition: INLINE 299 [encoded jpeg image] 300 --example-2-- 302 User Agents that recognize Multipart/Related will ignore the Content- 303 Disposition header's disposition type. Other User Agents will 304 process the Multipart/Related as Multipart/Mixed and may make use of 305 that header's information. 307 6. User Agent Requirements 309 User agents that do not recognize Multipart/Related shall, in 310 accordance with [MIME], treat the entire entity as Multipart/Mixed. 311 MIME User Agents that do recognize Multipart/Related entities but are 312 unable to process the given type should give the user the option of 313 suppressing the entire Multipart/Related body part shall be. 315 Existing MIME-capable mail user agents (MUAs) handle the existing 316 media types in a straightforward manner. For discrete media types 317 (e.g. text, image, etc.) the body of the entity can be directly 318 passed to a display process. Similarly the existing composite 319 subtypes can be reduced to handing one or more discrete types. 320 Handling Multipart/Related differs in that processing cannot be 321 reduced to handling the individual entities. 323 The following sections discuss what information the processing 324 application requires. 326 It is possible that an application specific "receiving agent" will 327 manipulate the entities for display prior to invoking actual 328 application process. Okie, above, is an example of this; it may need 329 a receiving agent to parse the document and substitute local file 330 names for the originator's file names. Other applications may just 331 require a table showing the correspondence between the local file 332 names and the originator's. The receiving agent takes responsibility 333 for such processing. 335 6.1 Data Requirements 336 MIME-capable mail user agents (MUAs) are required to provide the 337 application: 339 (a) the bodies of the MIME entities and the entity Content-* headers, 341 (b) the parameters of the Multipart/Related Content-type header, and 343 (c) the correspondence between each body's local file name, that 344 body's header data, and, if present, the body part's content-ID. 346 6.2 Storing Multipart/Related Entities 348 The Multipart/Related media type will be used for objects that have 349 internal linkages between the body parts. When the objects are 350 stored the linkages may require processing by the application or its 351 receiving agent. 353 6.3 Recursion 355 MIME is a recursive structure. Hence one must expect a Multi- 356 part/Related entity to contain other Multipart/Related entities. 357 When a Multipart/Related entity is being processed for display or 358 storage, any enclosed Multipart/Related entities shall be processed 359 as though they were being stored. 361 6.4 Configuration Considerations 363 It is suggested that MUAs that use configuration mechanisms, see 364 [CFG] for an example, refer to Multipart/Related as Multi- 365 part/Related/, were is the value of the "type" parame- 366 ter. 368 7. Security considerations 370 Security considerations relevant to Multipart/Related are identical 371 to those of the underlying content-type. 373 8. Acknowledgments 375 This proposal is the result of conversations the author has had with 376 many people. In particular, Harald A. Alvestrand, James Clark, 377 Charles Goldfarb, Gary Houston, Ned Freed, Ray Moody, and Don Stinch- 378 field, provided both encouragement and invaluable help. The author, 379 however, take full responsibility for all errors contained in this 380 document. 382 9. References 383 [822] Crocker, D., "Standard for the Format of ARPA Internet Text 384 Messages", August 1982, University of Delaware, RFC 822. 386 [CID] E. Levinson, J. Clark, "Message/External-Body Content-ID 387 Access Type", 12/26/1995, RFC 1873 Levinson, E., "Mes- 388 sage/External-Body Content-ID Access Type", work in 389 progress, ftp://ds.internic.net/internet-drafts/draft-ietf- 390 mimesgml-access-cid-01.txt. 392 [CFG] Borenstein, N., "A User Agent Configuration Mechanism For 393 Multimedia Mail Format Information", September 23, 1993, RFC 394 1524 396 [DISP] R. Troost, S. Dorner, "Communicating Presentation Informa- 397 tion in Internet Messages: The Content-Disposition Header", 398 June 7, 1995, RFC 1806 400 [MIME] Borenstein, N. and Freed, N., "MIME (Multipurpose Internet 401 Mail Extensions): Mechanisms for Specifying and Describing 402 the Format of Internet Message Bodies", June 1992, RFC 1341. 404 9. Author's address 406 Edward Levinson 407 47 Clive Street 408 Metuchen, NJ 08840-1060 409 USA 410 +1 908 494 1606 411