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