7Network Working Group J. Palme
8Request for Comments: 2557 Stockholm University/KTH
9Obsoletes: 2110 A. Hopmann
10Category: Standards Track Microsoft Corporation
12 Lotus Development Corporation
16 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
20 This document specifies an Internet standards track protocol for the
21 Internet community, and requests discussion and suggestions for
22 improvements. Please refer to the current edition of the "Internet
23 Official Protocol Standards" (STD 1) for the standardization state
24 and status of this protocol. Distribution of this memo is unlimited.
28 Copyright (C) The Internet Society (1999). All Rights Reserved.
32 HTML [RFC 1866] defines a powerful means of specifying multimedia
33 documents. These multimedia documents consist of a text/html root
34 resource (object) and other subsidiary resources (image, video clip,
35 applet, etc. objects) referenced by Uniform Resource Identifiers
36 (URIs) within the text/html root resource. When an HTML multimedia
37 document is retrieved by a browser, each of these component resources
38 is individually retrieved in real time from a location, and using a
39 protocol, specified by each URI.
41 In order to transfer a complete HTML multimedia document in a single
42 e-mail message, it is necessary to: a) aggregate a text/html root
43 resource and all of the subsidiary resources it references into a
44 single composite message structure, and b) define a means by which
45 URIs in the text/html root can reference subsidiary resources within
46 that composite message structure.
48 This document a) defines the use of a MIME multipart/related
49 structure to aggregate a text/html root resource and the subsidiary
50 resources it references, and b) specifies a MIME content-header
51 (Content-Location) that allow URIs in a multipart/related text/html
52 root body part to reference subsidiary resources in other body parts
53 of the same multipart/related structure.
58Palme, et al. Standards Track [Page 1]
60RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
63 While initially designed to support e-mail transfer of complete
64 multi-resource HTML multimedia documents, these conventions can also
65 be employed to resources retrieved by other transfer protocols such
66 as HTTP and FTP to retrieve a complete multi-resource HTML multimedia
67 document in a single transfer or for storage and archiving of
68 complete HTML-documents.
70 Differences between this and a previous version of this standard,
71 which was published as RFC 2110, are summarized in chapter 12.
75 1. Introduction ................................................. 3
76 2. Terminology ................................................. 4
77 2.1 Conformance requirement terminology ...................... 4
78 2.2 Other terminology ........................................ 4
79 3. Overview ..................................................... 6
80 4. The Content-Location MIME Content Header ..................... 6
81 4.1 MIME content headers ..................................... 6
82 4.2 The Content-Location Header .............................. 7
83 4.3 URIs of MHTML aggregates ................................. 8
84 4.4 Encoding and decoding of URIs in MIME header fields ...... 8
85 5. Base URIs for resolution of relative URIs .................... 9
86 6. Sending documents without linked objects ..................... 10
87 7. Use of the Content-Type "multipart/related" .................. 11
88 8. Usage of Links to Other Body Parts ........................... 13
89 8.1 General principle ........................................ 13
90 8.2 Resolution of URIs in text/html body parts ............... 13
91 8.3 Use of the Content-ID header and CID URLs ................ 14
92 9. Examples ..................................................... 14
93 9.1 Example of a HTML body without included linked objects ... 15
94 9.2 Example with an absolute URI to an embedded GIF picture .. 15
95 9.3 Example with relative URIs to embedded GIF pictures ...... 16
96 9.4 Example with a relative URI and no BASE available ........ 17
97 9.5 Example using CID URL and Content-ID header to an embedded
98 GIF picture .............................................. 18
99 9.6 Example showing permitted and forbidden references between
100 nested body parts ........................................ 19
101 10. Character encoding issues and end-of-line issues ............ 21
102 11. Security Considerations ..................................... 22
103 11.1 Security considerations not related to caching .......... 22
104 11.2 Security considerations related to caching .............. 23
105 12. Differences as compared to the previous version of this
106 proposed standard in RFC 2110 ............................... 24
107 13. Acknowledgments ............................................. 24
108 14. References .................................................. 25
109 15. Authors' Addresses .......................................... 27
110 16. Full Copyright Statement .................................... 28
114Palme, et al. Standards Track [Page 2]
116RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
121 There are a number of document formats (Hypertext Markup Language
122 [HTML2], Extended Markup Language [XML], Portable Document format
123 [PDF] and Virtual Reality Markup Language [VRML]) that specify
124 documents consisting of a root resource and a number of distinct
125 subsidiary resources referenced by URIs within that root resource.
126 There is an obvious need to be able to send such multi-resource
127 documents in e-mail [SMTP], [RFC822] messages.
129 The standard defined in this document specifies how to aggregate such
130 multi-resource documents in MIME-formatted [MIME1 to MIME5] messages
131 for precisely this purpose.
133 While this specification was developed to satisfy the specific
134 aggregation requirements of multi-resource HTML documents, it may
135 also be applicable to other multi-resource document representations
136 linked by URIs. While this is the case, there is no requirement that
137 implementations claiming conformance to this standard be able to
138 handle any URI linked document representations other than those whose
141 This aggregation into a single message of a root resource and the
142 subsidiary resources it references may also be applicable to
143 resources retrieved by other protocols such as HTTP or FTP, or to the
144 archiving of complete web pages as they appeared at a particular
147 An informational RFC will be published as a supplement to this
148 standard. The informational RFC will discuss implementation methods
149 and some implementation problems. Implementers are strongly
150 recommended to read this informational RFC when developing
151 implementations of this standard. You can find it through URL
152 http://www.dsv.su.se/~jpalme/ietf/mhtml.html.
154 This standard specifies that body parts to be referenced can be
155 identified either by a Content-ID (containing a Message-ID value) or
156 by a Content-Location (containing an arbitrary URL). The reason why
157 this standard does not only recommend the use of Content-ID-s is that
158 it should be possible to forward existing web pages via e-mail
159 without having to rewrite the source text of the web pages. Such
160 rewriting has several disadvantages, one of them that security
161 checksums will probably be invalidated.
170Palme, et al. Standards Track [Page 3]
172RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
1772.1 Conformance requirement terminology
179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
181 document are to be interpreted as described in [IETF-TERMS].
183 An implementation is not compliant if it fails to satisfy one or more
184 of the MUST requirements for the protocols it implements. An
185 implementation that satisfies all the MUST and all the SHOULD
186 requirements for its protocols is said to be "unconditionally
187 compliant"; one that satisfies all the MUST requirements but not all
188 the SHOULD requirements for its protocols is said to be
189 "conditionally compliant."
193 Most of the terms used in this document are defined in other RFCs.
195 Absolute URI, See Relative Uniform Resource Locators
196 AbsoluteURI [RELURL].
198 CID See Message/External Body Content-ID [MIDCID].
200 Content-Base This header was specified in RFC 2110, but has
201 been removed in this new version of the MHTML
204 Content-ID See Message/External Body Content-ID [MIDCID].
206 Content-Location MIME message or content part header with one
207 URI of the MIME message or content part body,
208 defined in section 4.2 below.
210 Content-Transfer- Conversion of a text into 7-bit octets as
211 Encoding specified in [MIME1] chapter 6.
217 Displayed text The text shown to the user reading a document
218 with a web browser. This may be different from
219 the HTML markup, see the definition of HTML
226Palme, et al. Standards Track [Page 4]
228RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
231 Header Field in a message or content heading
232 specifying the value of one attribute.
234 Heading Part of a message or content before the first
235 CRLFCRLF, containing formatted fields with
236 attributes of the message or content.
238 HTML See HTML 2 specification [HTML2].
240 HTML Aggregate HTML objects together with some or all objects,
241 objects to which the HTML object contains hyperlinks,
242 directly or indirectly.
244 HTML markup A file containing HTML encodings as specified
245 in [HTML] which may be different from the
246 displayed text which a person using a web
247 browser sees. For example, the HTML markup may
248 contain "<" where the displayed text
249 contains the character "<".
253 MIC Message Integrity Codes, codes use to verify
254 that a message has not been modified.
256 MIME See the MIME specifications [MIME1 to MIME5].
258 MUA Messaging User Agent.
260 PDF Portable Document Format, see [PDF].
262 Relative URI, See HTML 2 [HTML2] and RFC 1808 [RELURL].
265 URI, absolute and See RFC 1866 [HTML2].
268 URL See RFC 1738 [URL].
270 URL, relative See Relative Uniform Resource Locators [RELURL].
272 VRML See Virtual Reality Markup Language [VRML].
282Palme, et al. Standards Track [Page 5]
284RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
289 An aggregate document is a MIME-encoded message that contains a root
290 resource (object) as well as other resources linked to it via URIs.
291 These other resources may be required to display a multimedia
292 document based on the root resource (inline pictures, style sheets,
293 applets, etc.), or be the root resources of other multimedia
294 documents. It is important to keep in mind that aggregate documents
295 need to satisfy the differing needs of several audiences.
297 Mail sending agents might send aggregate documents as an encoding of
298 normal day-to-day electronic mail. Mail sending agents might also
299 send aggregate documents when a user wishes to mail a particular
300 document from the web to someone else. Finally mail sending agents
301 might send aggregate documents as automatic responders, providing
302 access to WWW resources for non-IP connected clients. Also with other
303 protocols such as HTTP or FTP, there may sometimes be a need to
304 retrieve aggregate documents. Receiving agents also have several
305 differing needs. Some receiving agents might be able to receive an
306 aggregate document and display it just as any other text content type
307 would be displayed. Others might have to pass this aggregate
308 document to a browsing program, and provisions need to be made to
311 Finally several other constraints on the problem arise. It is
312 important that it be possible for a document to be signed and for it
313 to be transmitted and displayed without breaking the message
314 integrity (MIC) checksum that is part of the signature.
3164. The Content-Location MIME Content Header
3184.1 MIME content headers
320 In order to resolve URI references to resources in other body parts,
321 one MIME content header is defined, Content-Location. This header can
322 occur in any message or content heading.
324 The syntax for this header is, using the syntax definition tools from
327 quoted-pair = ("\" text)
329 text = %d1-9 / ; Characters excluding CR and LF
333 WSP = SP / HTAB ; Whitespace characters
338Palme, et al. Standards Track [Page 6]
340RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
343 FWS = ([*WSP CRLF] 1*WSP) ; Folding white-space
345 ctext = NO-WS-CTL / ; Non-white-space controls
346 %d33-39 / ; The rest of the US-ASCII
347 %d42-91 / ; characters not including "(",
348 %d93-127 ; ")", or "\"
350 comment = "(" *([FWS] (ctext / quoted-pair / comment))
353 CFWS = *([FWS] comment) (([FWS] comment) / FWS)
355 content-location = "Content-Location:" [CFWS] URI [CFWS]
357 URI = absoluteURI | relativeURI
359 where URI is restricted to the syntax for URLs as defined in Uniform
360 Resource Locators [URL] until IETF specifies other kinds of URIs.
3624.2 The Content-Location Header
364 A Content-Location header specifies an URI that labels the content of
365 a body part in whose heading it is placed. Its value CAN be an
366 absolute or a relative URI. Any URI or URL scheme may be used, but
367 use of non-standardized URI or URL schemes might entail some risk
368 that recipients cannot handle them correctly.
370 An URI in a Content-Location header need not refer to an resource
371 which is globally available for retrieval using this URI (after
372 resolution of relative URIs). However, URI-s in Content-Location
373 headers (if absolute, or resolvable to absolute URIs) SHOULD still be
376 A Content-Location header can thus be used to label a resource which
377 is not retrievable by some or all recipients of a message. For
378 example a Content-Location header may label an object which is only
379 retrievable using this URI in a restricted domain, such as within a
380 company-internal web space. A Content-Location header can even
381 contain a fictitious URI. Such an URI need not be globally unique.
383 A single Content-Location header field is allowed in any message or
384 content heading, in addition to a Content-ID header (as specified in
385 [MIME1]) and, in Message headings, a Message-ID (as specified in
386 [RFC822]). All of these constitute different, equally valid body part
387 labels, and any of them may be used to satisfy a reference to a body
388 part. Multiple Content-Location header fields in the same message
389 heading are not allowed.
394Palme, et al. Standards Track [Page 7]
396RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
399 Example of a multipart/related structure containing body parts with
400 both Content-Location and Content-ID labels:
402 Content-Type: multipart/related; boundary="boundary-example";
407 Content-Type: text/html; charset="US-ASCII"
409 ... ... <IMG SRC="fiction1/fiction2"> ... ...
410 ... ... <IMG SRC="cid:97116092811xyz@foo.bar.net"> ... ...
413 Content-Type: image/gif
414 Content-ID: <97116092511xyz@foo.bar.net>
415 Content-Location: fiction1/fiction2
418 Content-Type: image/gif
419 Content-ID: <97116092811xyz@foo.bar.net>
420 Content-Location: fiction1/fiction3
4244.3 URIs of MHTML aggregates
426 The URI of an MHTML aggregate is not the same as the URI of its root.
427 The URI of its root will directly retrieve only the root resource
428 itself, even if it may cause a web browser to separately retrieve
429 in-line linked resources. If a Content-Location header field is used
430 in the heading of a multipart/related, this Content-Location SHOULD
431 apply to the whole aggregate, not to its root part.
433 When an URI referring to an MHTML aggregate is used to retrieve this
434 aggregate, the set of resources retrieved can be different from the
435 set of resources retrieved using the Content-Locations of its parts.
436 For example, retrieving an MHTML aggregate may return an old version,
437 while retrieving the root URI and its in-line linked objects may
438 return a newer version.
4404.4 Encoding and decoding of URIs in MIME header fields
4424.4.1 Encoding of URIs containing inappropriate characters
444 Some documents may contain URIs with characters that are
445 inappropriate for an RFC 822 header, either because the URI itself
446 has an incorrect syntax according to [URL] or the URI syntax standard
450Palme, et al. Standards Track [Page 8]
452RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
455 has been changed to allow characters not previously allowed in MIME
456 headers. These URIs cannot be sent directly in a message header. If
457 such a URI occurs, all spaces and other illegal characters in it must
458 be encoded using one of the methods described in [MIME3] section 4.
459 This encoding MUST only be done in the header, not in the HTML text.
460 Receiving clients MUST decode the [MIME3] encoding in the heading
461 before comparing URIs in body text to URIs in Content-Location
464 The charset parameter value "US-ASCII" SHOULD be used if the URI
465 contains no octets outside of the 7-bit range. If such octets are
466 present, the correct charset parameter value (derived e.g. from
467 information about the HTML document the URI was found in) SHOULD be
468 used. If this cannot be safely established, the value "UNKNOWN-8BIT"
469 [RFC 1428] MUST be used.
471 Note, that for the matching of URIs in text/html body parts to URIs
472 in Content-Location headers, the value of the charset parameter is
473 irrelevant, but that it may be relevant for other purposes, and that
474 incorrect labeling MUST, therefore, be avoided. Warning: Irrelevance
475 of the charset parameter may not be true in the future, if different
476 character encodings of the same non-English filename are used in
4794.4.2 Folding of long URIs
481 Since MIME header fields have a limited length and long URIs can
482 result in Content-Location headers that exceed this length, Content-
483 Location headers may have to be folded.
485 Encoding as discussed in clause 4.4.1 MUST be done before such
486 folding. After that, the folding can be done, using the algorithm
487 defined in [URLBODY] section 3.1.
4894.4.3 Unfolding and decoding of received URLs in MIME header fields
491 Upon receipt, folded MIME header fields should be unfolded, and then
492 any MIME encoding should be removed, to retrieve the original URI.
4945. Base URIs for resolution of relative URIs
496 Relative URIs inside the contents of MIME body parts are resolved
497 relative to a base URI using the methods for resolving relative URIs
498 described in [RELURL]. In order to determine this base URI, the
499 first-applicable method in the following list applies.
506Palme, et al. Standards Track [Page 9]
508RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
511 (a) There is a base specification inside the MIME body part
512 containing the relative URI which resolves relative URIs into
513 absolute URIs. For example, HTML provides the BASE element for
516 (b) There is a Content-Location header in the immediately surrounding
517 heading of the body part and it contains an absolute URI. This
518 URI can serve as a base in the same way as a requested URI can
519 serve as a base for relative URIs within a file retrieved via
522 (c) If necessary, step (b) can be repeated recursively to find a
523 suitable Content-Location header in a surrounding multi-part or
526 (d) If the MIME object is returned in a HTTP response, use the URI
527 used to initiate the request
529 (e) When the methods above do not yield an absolute URI, a base URL
530 of "thismessage:/" MUST be employed. This base URL has been
531 defined for the sole purpose of resolving relative references
532 within a multipart/related structure when no other base URI is
535 This is also described in other words in section 8.2 below.
5376. Sending documents without linked objects
539 If a text/html resource (object) is sent without subsidiary
540 resources, to which it refers, it MAY be sent by itself. In this
541 case, embedding it in a multipart/related structure is not necessary.
543 Such a text/html resource may either contain no URIs, or URIs which
544 the recipient is expected to retrieve (if possible) via a URI
545 specified protocol. A text/html resource may also be sent with
546 unresolvable links in special cases, such as when two authors
547 exchange drafts of unfinished resources.
549 Inclusion of URIs referencing resources which the recipient has to
550 retrieve via an URI specified protocol may not work for some
551 recipients. This is because not all e-mail recipients have full
552 Internet connectivity, or because URIs which work for a sender will
553 not work for a recipient. This occurs, for example, when an URI
554 refers to a resource within a company-internal network that is not
555 accessible from outside the company.
562Palme, et al. Standards Track [Page 10]
564RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
5677. Use of the Content-Type "multipart/related"
569 If a message contains one or more MIME body parts containing URIs and
570 also contains as separate body parts, resources, to which these URIs
571 (as defined, for example, in HTML 2.0 [HTML2]) refer, then this whole
572 set of body parts (referring body parts and referred-to body parts)
573 SHOULD be sent within a multipart/related structure as defined in
576 Even though headers can occur in a message that lacks an associated
577 multipart/related structure, this standard only covers their use for
578 resolution of URIs between body parts inside a multipart/related
579 structure. This standard does cover the case where a resource in a
580 nested multipart/related structure contains URIs that reference MIME
581 body parts in another multipart/related structure, in which it is
582 enclosed. This standard does not cover the case where a resource in a
583 multipart/related structure contains URIs that reference MIME body
584 parts in another parallel or nested multipart/related structure, or
585 in another MIME message, even if methods similar to those described
586 in this standard are used. Implementers who employ such URIs are
587 warned that receiving agents implementing this standard may not be
588 able to process such references.
590 When the start body part of a multipart/related structure is an
591 atomic object, such as a text/html resource, it SHOULD be employed as
592 the root resource of that multipart/related structure. When the start
593 body part of a multipart/related structure is a multipart/alternative
594 structure, and that structure contains at least one alternative body
595 part which is a suitable atomic object, such as a text/html resource,
596 then that body part SHOULD be employed as the root resource of the
597 aggregate document. Implementers are warned, however, that some
598 receiving agents treat multipart/alternative as if it had been
599 multipart/mixed (even though MIME [MIME1] requires support for
600 multipart/alternative).
602 [REL] specifies that a type parameter is mandatory in a "Content-
603 Type: multipart/related" header, and requires that it be employed to
604 specify the type of the multipart/related start object. Thus, the
605 type parameter value shall be "multipart/alternative", when the start
606 part is of "Content-type multipart/alternative", even if the actual
607 root resource is of type "text/html". In addition, if the
608 multipart/related start object is not the first body part in a
609 multipart/related structure, [REL] further requires that its
610 Content-ID MUST be specified as the value of a start parameter in the
611 "Content-Type: multipart/related" header.
618Palme, et al. Standards Track [Page 11]
620RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
623 When rendering a resource in a multipart/related structure, URI
624 references within that resource can be satisfied by body parts within
625 the same multipart/related structure (see section 8.2 below). This is
628 (a) For those recipients who only have email but not full Internet
631 (b) For those recipients who for other reasons, such as firewalls or
632 the use of company-internal links, cannot retrieve URI referenced
633 resources via URI specified protocols.
635 Note, that this means that you can, via e-mail, send text/html
636 objects which includes URIs which the recipient cannot resolve
637 via HTTP or other connectivity-requiring URIs.
639 (c) To send a document whose content is preserved even if the
640 resources to which embedded URIs refer are later changed or
643 (d) For resources which are not available for protocol based
646 (e) To speed up access.
648 When a sending MUA sends objects which were retrieved from the WWW,
649 it SHOULD maintain their WWW URIs. It SHOULD not transform these URIs
650 into some other URI form prior to transmitting them. This will allow
652 the receiving MUA to both verify MICs included with the message, as
653 well as verify the documents against their WWW counterpoints, if this
656 In certain cases this will not work - for example, if a resource
657 contains URIs as parameters to objects and applets. In such a case,
658 it might be better to rewrite the document before sending it. This
659 problem is discussed in more detail in the informational RFC which
660 will be published as a supplement to this standard.
662 Within a multipart/related structure, each body part MUST have, if
663 assigned, a different Content-ID header value and a Content-Location
664 header field values which resolve to a different URI.
666 Two body parts in the same multipart/related structure can have the
667 same relative Content-Location header value, only if when resolved to
668 absolute URIs they become different.
674Palme, et al. Standards Track [Page 12]
676RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
6798. Usage of Links to Other Body Parts
683 A body part, such as a text/html body part, may contain URIs that
684 reference resources which are included as body parts in the same
685 message -- in detail, as body parts within the same multipart/related
686 structure. Often such URI linked resources are meant to be displayed
687 inline to the viewer of the referencing body part; for example,
688 objects referenced with the SRC attribute of the IMG element in HTML
689 2.0 [HTML2]. New elements and attributes with this property are
690 proposed in the ongoing development of HTML (examples: applet, frame,
691 profile, OBJECT, classid, codebase, data, SCRIPT). A sender might
692 also want to send a set of HTML documents which the reader can
693 traverse, and which are related with the attribute href of the A
696 If a user retrieves and displays a web page formed from a text/html
697 resource, and the subsidiary resources it references, and merely
698 saves the text/html resource, that user may not at a later time be
699 able to retrieve and display the web page as it appeared when saved.
700 The format described in this standard can be used to archive and
701 retrieve all of the resources required to display the web page, as it
702 originally appeared at a certain moment of time, in one aggregate
705 In order to send or store complete such messages, there is a need to
706 specify how a URI in one body part can reference a resource in
7098.2 Resolution of URIs in text/html body parts
711 The resolution of inline, retrieval and other kinds of URIs in
712 text/html body parts is performed in the following way:
714 (a) Unfold multiple line header values according to [URLBODY]. Do NOT
715 however translate character encodings of the kind described in
716 [URL]. Example: Do not transform "a%2eb/c%20d" into "a/b/c d".
718 (b) Remove all MIME encodings, such as content-transfer encoding and
719 header encodings as defined in MIME part 3 [MIME3] Do NOT however
720 translate character encodings of the kind described in [URL].
721 Example: Do not transform "a%2eb/c%20d" into "a/b/c d".
723 (c) Try to resolve all relative URIs in the HTML content and in
724 Content-Location headers using the procedure described in chapter
725 5 above. The result of this resolution can be an absolute URI, or
726 an absolute URI with the base "thismessage:/" as specified in
730Palme, et al. Standards Track [Page 13]
732RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
737 (d) For each referencing URI in a text/html body part, compare the
738 value of the referencing URI after resolution as described in (a)
739 and (b), with the URI derived from Content-ID and Content-
740 Location headers for other body parts within the same or a
741 surrounding Multipart/related structure. If the strings are
742 identical, octet by octet, then the referencing URI references
743 that body part. This comparison will only succeed if the two URIs
744 are identical. This means that if one of the two URIs to be
745 compared was a fictitious absolute URI with the base
746 "thismessage:/", the other must also be such a fictitious
747 absolute URI, and not resolvable to a real absolute URI.
749 (e) If (d) fails, try to retrieve the URI referenced resource
750 hyperlink through ordinary Internet lookup. Resolution of URIs of
751 the URL-types "mid" or "cid" to other content-parts, outside the
752 same multipart/related structure, or in other separately sent
753 messages, is not covered by this standard, and is thus neither
754 encouraged nor forbidden.
7568.3 Use of the Content-ID header and CID URLs
758 When URIs employing a CID (Content-ID) scheme as defined in [URL] and
759 [MIDCID] are used to reference other body parts in an MHTML
760 multipart/related structure, they MUST only be matched against
761 Content-ID header values, and not against Content-Location header
762 with CID: values. Thus, even though the following two headers are
763 identical in meaning, only the Content-ID value will be matched, and
764 the Content-Location value will be ignored.
766 Content-ID: <foo@bar.net>
767 Content-Location: CID: foo@bar.net
769 Note: Content-IDs MUST be globally unique [MIME1]. It is thus not
770 permitted to make them unique only within a message or within a
771 single multipart/related structure.
775 Warning: The examples are provided for illustrative purposes only. If
776 there is a contradiction between the explanatory text and the
777 examples in this standard, then the explanatory text is normative.
779 Notation: The examples contain indentation to show the structure, the
780 real objects should not be indented in this way.
786Palme, et al. Standards Track [Page 14]
788RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
7919.1 Example of a HTML body without included linked objects
793 The first example is the simplest form of an HTML email message. This
794 message does not contain an aggregate HTML object, but simply a
795 message with a single HTML body part. This body part contains a URI
796 but the messages does not contain the resource referenced by that
797 URI. To retrieve the resource referenced by the URI the receiving
798 client would need either IP access to the Internet, or an electronic
803 Subject: A simple example
805 Content-Type: text/html; charset="iso-8859-1"
806 Content-Transfer-Encoding: 8bit
811 <h1>Acute accent</h1>
812 The following two lines look have the same screen rendering:<p>
813 E with acute accent becomes É.<br>
814 E with acute accent becomes É.<p>
815 Try clicking <a href="http://www.ietf.cnri.reston.va.us/">
8199.2 Example with an absolute URI to an embedded GIF picture
821 The second example is an HTML message which includes a single image,
822 referenced using the Content-Location mechanism.
826 Subject: A simple example
828 Content-Type: multipart/related; boundary="boundary-example";
829 type="text/html"; start="<foo3@foo1@bar.net>"
832 Content-Type: text/html;charset="US-ASCII"
833 Content-ID: <foo3@foo1@bar.net>
835 ... text of the HTML document, which might contain a URI
836 referencing a resource in another body part, for example
837 through a statement such as:
838 <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
842Palme, et al. Standards Track [Page 15]
844RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
851 http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
852 Content-Type: IMAGE/GIF
853 Content-Transfer-Encoding: BASE64
855 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
856 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
8619.3 Example with relative URIs to embedded GIF pictures
863 In this example, a Content-Location header field in the outermost
864 heading will be a base to all relative URLs, also inside the HTML
869 Subject: A simple example
871 Content-Location: http://www.ietf.cnri.reston.va.us/
872 Content-Type: multipart/related; boundary="boundary-example";
876 Content-Type: text/html; charset="ISO-8859-1"
877 Content-Transfer-Encoding: QUOTED-PRINTABLE
879 ... text of the HTML document, which might contain URIs
880 referencing resources in other body parts, for example through
883 <IMG SRC="images/ietflogo1.gif" ALT="IETF logo1">
884 <IMG SRC="images/ietflogo2.gif" ALT="IETF logo2">
885 <IMG SRC="images/ietflogo3.gif" ALT="IETF logo3">
887 Example of a copyright sign encoded with Quoted-Printable: =A9
888 Example of a copyright sign mapped onto HTML markup: ¨
892 http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif
893 ; Note - Absolute Content-Location does not require a
898Palme, et al. Standards Track [Page 16]
900RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
903 Content-Type: IMAGE/GIF
904 Content-Transfer-Encoding: BASE64
906 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
907 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
911 Content-Location: images/ietflogo2.gif
912 ; Note - Relative Content-Location is resolved by base
913 ; specified in the Multipart/Related Content-Location heading
914 Content-Transfer-Encoding: BASE64
916 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
917 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
922 http://www.ietf.cnri.reston.va.us/images/ietflogo3.gif
923 Content-Transfer-Encoding: BASE64
925 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
926 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
9319.4 Example with a relative URI and no BASE available
935 Subject: A simple example
937 Content-Type: multipart/related; boundary="boundary-example";
941 Content-Type: text/html; charset="iso-8859-1"
942 Content-Transfer-Encoding: QUOTED-PRINTABLE
944 ... text of the HTML document, which might contain a URI
945 referencing a resource in another body part, for example
946 through a statement such as:
947 <IMG SRC="ietflogo.gif" ALT="IETF logo">
948 Example of a copyright sign encoded with Quoted-Printable: =A9
949 Example of a copyright sign mapped onto HTML markup: ¨
954Palme, et al. Standards Track [Page 17]
956RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
960 Content-Location: ietflogo.gif
961 Content-Type: IMAGE/GIF
962 Content-Transfer-Encoding: BASE64
964 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
965 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
9709.5 Example using CID URL and Content-ID header to an embedded GIF
975 Subject: A simple example
977 Content-Type: multipart/related; boundary="boundary-example";
981 Content-Type: text/html; charset="US-ASCII"
983 ... text of the HTML document, which might contain a URI
984 referencing a resource in another body part, for example
985 through a statement such as:
986 <IMG SRC="cid:foo4@foo1@bar.net" ALT="IETF logo">
989 Content-Location: CID:something@else ; this header is disregarded
990 Content-ID: <foo4@foo1@bar.net>
991 Content-Type: IMAGE/GIF
992 Content-Transfer-Encoding: BASE64
994 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
995 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
1010Palme, et al. Standards Track [Page 18]
1012RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
10159.6 Example showing permitted and forbidden references between nested
1018 This example shows in which cases references are allowed between
1019 multiple multipart/related body parts in a message.
1023 Subject: A simple example
1025 Content-Type: multipart/related; boundary="boundary-example-1";
1028 --boundary-example-1
1029 Content-Type: text/html;charset="US-ASCII"
1030 Content-ID: <foo3@foo1@bar.net>
1032 The image reference below will be resolved with the image
1033 in the next body part.
1034 <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
1035 ALT="IETF logo with white background">
1037 The image reference below cannot be resolved within this
1038 MIME message, since it contains a reference from an outside
1039 body part to an inside body part, which is not supported
1041 <IMG SRC=images/ietflogo2e.gif"
1042 ALT="IETF logo with transparent background">
1044 The anchor reference immediately below will be resolved with
1045 the nested text/html body part below:
1046 <A HREF="http://www.ietf.cnri.reston.va.us/more-info>
1049 The anchor reference immediately below will be resolved with
1050 the nested text/html body part below:
1051 <A HREF="http://www.ietf.cnri.reston.va.us/even-more-info>
1054 --boundary-example-1
1056 http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
1057 Content-Type: IMAGE/GIF
1058 Content-Transfer-Encoding: BASE64
1060 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
1061 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
1066Palme, et al. Standards Track [Page 19]
1068RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
1071 --boundary-example-1
1073 http://www.ietf.cnri.reston.va.us/more-info
1074 Content-Type: multipart/related; boundary="boundary-example-2";
1076 --boundary-example-2
1077 Content-Type: text/html;charset="US-ASCII"
1078 Content-ID: <foo4@foo1@bar.net>
1080 The image reference below will be resolved with the image
1081 in the surrounding multipart/related above.
1082 <IMG SRC="images/ietflogo.gif"
1083 ALT="IETF logo with white background">
1085 The image reference below will be resolved with the image
1086 inside the current nested multipart/related below.
1087 <IMG SRC=images/ietflogo2e.gif"
1088 ALT="IETF logo with transparent background">
1090 --boundary-example-2
1091 Content-Location: http:images/ietflogo2.gif
1092 Content-Type: IMAGE/GIF
1093 Content-Transfer-Encoding: BASE64
1095 R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4
1096 SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/eQnNzjHNzlGtrjGNjhFpae1pa
1099 --boundary-example-2--
1100 --boundary-example-1
1102 http://www.ietf.cnri.reston.va.us/even-more-info
1103 Content-Type: multipart/related; boundary="boundary-example-3";
1105 --boundary-example-3
1106 Content-Type: text/html;charset="US-ASCII"
1107 Content-ID: <4@foo@bar.net>
1109 The image reference below will be resolved with the image
1110 inside the current nested multipart/related below.
1111 <IMG SRC=images/ietflogo2d.gif"
1112 ALT="IETF logo with shadows">
1114 The image reference below cannot be resolved according to
1115 this standard since references between parallel multipart/
1116 related structures are not supported.
1117 <IMG SRC=images/ietflogo2e.gif"
1118 ALT="IETF logo with transparent background">
1122Palme, et al. Standards Track [Page 20]
1124RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
1127 --boundary-example-3
1128 Content-Location: http:images/ietflogo2d.gif
1129 Content-Type: IMAGE/GIF
1130 Content-Transfer-Encoding: BASE64
1132 R0lGODlhGAGgANX/AMDAwCkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nz
1133 c3t7e4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v
1136 --boundary-example-3--
1137 --boundary-example-1--
113910. Character encoding issues and end-of-line issues
1141 For the encoding of characters in HTML documents and other text
1142 documents into a MIME-compatible octet stream, the following
1143 mechanisms are relevant:
1145 - HTML [HTML2], [HTML-I18N] as an application of SGML [SGML] allows
1146 characters to be denoted by character entities as well as by
1147 numeric character references (e.g. "Latin small letter a with
1148 acute accent" may be represented by "á" or "á") in the
1151 - HTML documents, in common with other documents of the MIME
1152 Content-Type "text", can be represented in MIME using one of
1153 several character encodings. The MIME Content-Type "charset"
1154 parameter value indicates the particular encoding used. For the
1155 exact meaning and use of the "charset" parameter, please see
1158 Note that the "charset" parameter refers only to the MIME
1159 character encoding. For example, the string "á" can be sent
1160 in MIME with "charset=US-ASCII", while the raw character "Latin
1161 small letter a with acute accent" cannot.
1163 The above mechanisms are well defined and documented, and therefore
1164 not further explained here. In sending a message, all the above
1165 mentioned mechanisms MAY be used, and any mixture of them MAY occur
1166 when sending the document in MIME format. Receiving user agents
1167 (together with any Web browser they may use to display the document)
1168 MUST be capable of handling any combinations of these mechanisms.
1172 - Any documents including HTML documents that contain octet values
1173 outside the 7-bit range need a content-transfer-encoding applied
1174 before transmission over certain transport protocols [MIME1,
1178Palme, et al. Standards Track [Page 21]
1180RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
1185 - The MIME standard [MIME2] requires that e-mailed documents of
1186 "Content-Type: Text/ MUST be in canonical form before a Content-
1187 Transfer-Encoding is applied, i.e. that line breaks are encoded as
1188 CRLFs, not as bare CRs or bare LFs or something else. This is in
1189 contrast to [HTTP] where section 3.6.1 allows other
1190 representations of line breaks.
1192 Note that this might cause problems with integrity checks based on
1193 checksums, which might not be preserved when moving a document from
1194 the HTTP to the MIME environment. If a document has to be converted
1195 in such a way that a checksum based message integrity check becomes
1196 invalid, then this integrity check header SHOULD be removed from the
1199 Other sources of problems are Content-Encoding used in HTTP but not
1200 allowed in MIME, and character sets that are not able to represent
1201 line breaks as CRLF. A good overview of the differences between HTTP
1202 and MIME with regards to Content-Type: "text" can be found in [HTTP],
1205 Some transport mechanisms may specify a default "charset" parameter
1206 if none is supplied [HTTP, MIME1]. Because the default differs for
1207 different mechanisms, when HTML is transferred through e-mail, the
1208 charset parameter SHOULD be included, rather than relying on the
121111. Security Considerations
121311.1 Security considerations not related to caching
1215 It is possible for a message sender to misrepresent the source of a
1216 multipart/related body part to a message recipient by labeling it
1217 with a Content-Location URI that references another resource.
1218 Therefore, message recipients should only interpret Content-Location
1219 URIs as labeling a body part for the resolution of references from
1220 body parts in the same multipart/related message structure, and not
1221 as the source of a resource, unless this can be verified by other
1224 URIs, especially File URIs, if used without change in a message, may
1225 inadvertently reveal information that was not intended to be revealed
1226 outside a particular security context. Message senders should take
1227 care when constructing messages containing the new header fields,
1228 defined in this standard, that they are not revealing information
1229 outside of any security contexts to which they belong.
1234Palme, et al. Standards Track [Page 22]
1236RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
1239 Some resource servers hide passwords and tickets (access tokens to
1240 information which should not be reveled to others) and other
1241 sensitive information in non-visible fields or URIs within a
1242 text/html resource. If such a text/html resource is forwarded in an
1243 email message, this sensitive information may be inadvertently
1246 Since HTML documents can either directly contain executable content
1247 (i.e., JavaScript) or indirectly reference executable content (The
1248 "INSERT" specification, Java). It is exceedingly dangerous for a
1249 receiving User Agent to execute content received in a mail message
1250 without careful attention to restrictions on the capabilities of that
1253 HTML-formatted messages can be used to investigate user behaviour,
1254 for example to break anonymity, in ways which invade the privacy of
1255 individuals. If you send a message with a inline link to an object
1256 which is not itself included in the message, the recipients mailer or
1257 browser may request that object through HTTP. The HTTP transaction
1258 will then reveal who is reading the message. Example: A person who
1259 wants to find out who is behind an anonymous user identity, or from
1260 which workstation a user is reading his mail, can do this by sending
1261 a message with an inline link and then observe from where this link
1262 is used to request the object.
126411.2 Security considerations related to caching
1266 There is a well-known problem with the caching of directly retrieved
1267 web resources. A resource retrieved from a cache may differ from that
1268 re-retrieved from its source. This problem, also manifests itself
1269 when a copy of a resource is delivered in a multipart/related
1272 When processing (rendering) a text/html body part in an MHTML
1273 multipart/related structure, all URIs in that text/html body part
1274 which reference subsidiary resources within the same
1275 multipart/related structure SHALL be satisfied by those resources and
1276 not by resources from any another local or remote source.
1278 Therefore, if a sender wishes a recipient to always retrieve an URI
1279 referenced resource from its source, an URI labeled copy of that
1280 resource MUST NOT be included in the same multipart/related
1283 In addition, since the source of a resource received in a
1284 multipart/related structure can be misrepresented (see 11.1 above),
1285 if a resource received in multipart/related structure is stored in a
1286 cache, it MUST NOT be retrieved from that cache other than by a
1290Palme, et al. Standards Track [Page 23]
1292RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
1295 reference contained in a body part of the same multipart/related
1296 structure. Failure to honor this directive will allow a
1297 multipart/related structure to be employed as a Trojan Horse. For
1298 example, to inject bogus resources (i.e. a misrepresentation of a
1299 competitor's Web site) into a recipient's generally accessible Web
130212. Differences as compared to the previous version of this proposed
1303 standard in RFC 2110
1305 The specification has been changed to show that the formats described
1306 do not only apply to multipart MIME in email, but also to multipart
1307 MIME transferred through other protocols such as HTTP or FTP.
1309 In order to agree with [RELURL], Content-Location headers in
1310 multipart Content-Headings can now be used as a base to resolve
1311 relative URIs in their component parts, but only if no base URI can
1312 be derived from the component part itself. Base URIs in Content-
1313 Location header fields in inner headings have precedence over base
1314 URIs in outer multipart headings.
1316 The Content-Base header, which was present in RFC 2110, has been
1317 removed. A conservative implementor may choose to accept this header
1318 in input for compatibility with implementations of RFC 2110, but MUST
1319 never send any Content-Base header, since this header is not any more
1320 a part of this standard.
1322 A section 4.4.1 has been added, specifying how to handle the case of
1323 sending a body part whose URI does not agree with the correct URI
1326 The handling of relative and absolute URIs for matching between body
1327 parts have been merged into a single description, by specifying that
1328 relative URIs, which cannot be resolved otherwise, should be handled
1329 as if they had been given the URL "thismessage:/".
1333 Harald T. Alvestrand, Richard Baker, Isaac Chan, Dave Crocker, Martin
1334 J. Duerst, Lewis Geer, Roy Fielding, Ned Freed, Al Gilman, Paul
1335 Hoffman, Andy Jacobs, Richard W. Jesmajian, Mark K. Joseph, Greg
1336 Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay Levitt,
1337 Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Martyn W.
1338 Peck, Pete Resnick, Jon Smirl, Einar Stefferud, Jamie Zawinski, Steve
1339 Zilles and several other people have helped us with preparing this
1340 document. We alone take responsibility for any errors which may still
1346Palme, et al. Standards Track [Page 24]
1348RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
1353 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
1354 Specifications: ABNF", RFC 2234, November 1997.
1356 [CONDISP] Troost, R. and S. Dorner, "Communicating Presentation
1357 Information in Internet Messages: The Content-
1358 Disposition Header", RFC 2183, August 1997.
1360 [HOSTS] Braden, R., Ed., "Requirements for Internet Hosts --
1361 Application and Support", STD 3, RFC 1123, October
1364 [HTML-I18N] Yergeau, F., Nicol, G. Adams, G. and M. Duerst:
1365 "Internationalization of the Hypertext Markup
1366 Language", RFC 2070, January 1997.
1368 [HTML2] Berners-Lee, T. and D. Connolly: "Hypertext Markup
1369 Language - 2.0", RFC 1866, November 1995.
1371 [HTML3.2] Dave Raggett: HTML 3.2 Reference Specification, W3C
1372 Recommendation, January 1997, at URL
1373 http://www.w3.org/TR/REC-html32.html
1375 [HTTP] Berners-Lee, T., Fielding, R. and H. Frystyk,
1376 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
1379 [IETF-TERMS] Bradner, S., "Key words for use in RFCs to Indicate
1380 Requirements Levels", BCP 14, RFC 2119, March 1997.
1382 [INFO] J. Palme: Sending HTML in MIME, an informational
1383 supplement to the RFC: MIME Encapsulation of
1384 Aggregate Documents, such as HTML (MHTML), Work in
1387 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1390 [MIDCID] Levinson, E., "Content-ID and Message-ID Uniform
1391 Resource Locators", RFC 2387, August 1998.
1393 [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet
1394 Mail Extensions (MIME) Part One: Format of Internet
1395 Message Bodies", RFC 2045, December 1996.
1402Palme, et al. Standards Track [Page 25]
1404RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
1407 [MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet
1408 Mail Extensions (MIME) Part Two: Media Types", RFC
1409 2046, December 1996.
1411 [MIME3] Moore, K., "MIME (Multipurpose Internet Mail
1412 Extensions) Part Three: Message Header Extensions for
1413 Non-ASCII Text", RFC 2047, December 1996.
1415 [MIME4] Freed, N., Klensin, J. and J. Postel, "Multipurpose
1416 Internet Mail Extensions (MIME) Part Four:
1417 Registration Procedures", RFC 2048, January 1997.
1419 [MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet
1420 Mail Extensions (MIME) Part Five: Conformance
1421 Criteria and Examples", RFC 2049, November 1996.
1423 [NEWS] Horton, M. and R. Adams: "Standard for interchange of
1424 USENET messages", RFC 1036, December 1987.
1426 [PDF] Tim Bienz and Richar Cohn: "Portable Document Format
1427 Reference Manual", Addison-Wesley, Reading, MA, USA,
1428 1993, ISBN 0-201-62628-4.
1430 [REL] Levinson, E., "The MIME Multipart/Related Content-
1431 Type", RFC 2389, August 1998.
1433 [RELURL] Fielding, R., "Relative Uniform Resource Locators",
1434 RFC 1808, June 1995.
1436 [RFC822] Crocker, D., "Standard for the format of ARPA
1437 Internet text messages." STD 11, RFC 822, August
1440 [SGML] ISO 8879. Information Processing -- Text and Office -
1441 Standard Generalized Markup Language (SGML), 1986.
1442 <URL:http://www.iso.ch/cate/d16387.html>
1444 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10,
1445 RFC 821, August 1982.
1447 [URL] Berners-Lee, T., Masinter, L. and M. McCahill,
1448 "Uniform Resource Locators (URL)", RFC 1738, December
1451 [URLBODY] Freed, N. and K. Moore, "Definition of the URL MIME
1452 External-Body Access-Type", RFC 2017, October 1996.
1458Palme, et al. Standards Track [Page 26]
1460RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
1463 [VRML] Gavin Bell, Anthony Parisi, Mark Pesce: "Virtual
1464 Reality Modeling Language (VRML) Version 1.0 Language
1465 Specification." May 1995,
1466 http://www.vrml.org/Specifications/.
1468 [XML] Extensible Markup Language, published by the World
1469 Wide Web Consortium, URL http://www.w3.org/XML/
147115. Authors' Addresses
1473 For contacting the editors, preferably write to Jacob Palme.
1476 Stockholm University and KTH
1478 S-164 40 Kista, Sweden
1480 Phone: +46-8-16 16 67
1481 Fax: +46-8-783 08 29
1482 EMail: jpalme@dsv.su.se
1486 Microsoft Corporation
1490 Phone: +1-425-703-8238
1491 EMail: alexhop@microsoft.com
1495 Lotus Development Corporation
1496 55 Cambridge Parkway
1497 Cambridge MA 02142-1295
1499 EMail: Shelness@lotus.com
1502 Working group chairman:
1514Palme, et al. Standards Track [Page 27]
1516RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
151916. Full Copyright Statement
1521 Copyright (C) The Internet Society (1999). All Rights Reserved.
1523 This document and translations of it may be copied and furnished to
1524 others, and derivative works that comment on or otherwise explain it
1525 or assist in its implementation may be prepared, copied, published
1526 and distributed, in whole or in part, without restriction of any
1527 kind, provided that the above copyright notice and this paragraph are
1528 included on all such copies and derivative works. However, this
1529 document itself may not be modified in any way, such as by removing
1530 the copyright notice or references to the Internet Society or other
1531 Internet organizations, except as needed for the purpose of
1532 developing Internet standards in which case the procedures for
1533 copyrights defined in the Internet Standards process must be
1534 followed, or as required to translate it into languages other than
1537 The limited permissions granted above are perpetual and will not be
1538 revoked by the Internet Society or its successors or assigns.
1540 This document and the information contained herein is provided on an
1541 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1542 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1543 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1544 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1545 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1570Palme, et al. Standards Track [Page 28]