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