Network Working Group R. Hentze draft-palme-mhtml-status-2000-00.txt A. Muto Category: Informational Stockholm University May 2000 Sending HTML in E-mail - Status Report 2000 Status of this document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. Abstract This document investigates the current status of the implementation of the MHTML standard in April 2000. MHTML is a proposed standard that defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references. It also specifies a MIME content-header (Content- Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. The purpose of this report is to examine whether the MHTML standard can be elevated from the proposed standard level to the draft standard level in the Internet Standards Track. This requires that at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained. The testing comprised eight e-mail clients. To check whether the tested clients support the MHTML standard, a number of different methods were used. The e-mail clients' abilities to produce MHTML messages were analyzed. To check the MHTML generated by the e-mail clients, six MHTML messages were sent. Their receipt capabilities were tested with fifteen messages, each with different MHTML features. Our testing also included pairwise compatibility and re- sending of MHTML messages. Our results show that most of the tested MHTML functions are supported by the tested e-mail clients. One common problem is references of the Content-Location kind. We suggest that the problems concerning Content-Location references are taken into account in the next version of the MHTML standard. Only one of the tested e-mail clients produces Content-Location when sending MHTML. This may imply that the function should be removed from the standard. The conclusion is that the MHTML standard is not yet without changes ready to be elevated to the next level in the Internet Standards Track. To advance to that level the MHTML standard must be revised and/or more features must be added to the e-mail clients. Table of Contents 1. Introduction 2. Where to Find more Information and Comment on this Document 3. Overview 3.1 Example 4. Testing Methods 4.1 Methods of Producing MHTML Messages 4.2 Correctness of Messages Sent by the Tested Clients 4.3 Test Messages for Receipt of MHTML 4.4 Pairwise Compatibility 4.5 In-out Testing 5. Testing Results 5.1 Testing for receipt of MHTML 5.2 Testing for submission of MHTML 6. Conclusions 7. Acknowledgments 8. Security Considerations 9. References 10. Authors' Addresses 11. Full Copyright Statement 12. Appendix A - More Detailed Testing Results 12.1 Microsoft Outlook Express 12.2 Netscape Messenger 12.3 Qualcomm Eudora Pro 12.4 Pine 12.5 Juno 12.6 MSN Hotmail 12.7 Yahoo! Mail 12.8 KOM 2000 1. Introduction To satisfy the need of sending multi-resource documents in e-mail, the RFC "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)" [MHTML97] was published in March 1997. That document specifies how to aggregate multi-resource documents in MIME formatted [MIME1, MIME2, MIME-IMB] messages. In March 1999, [MHTML97] was revised in [MHTML99], which is a proposed standard on the entry-level of the Internet Standards Track. To elevate the MHTML standard to the "Draft Standard" level at least two independent and interoperable implementations from different code bases must have been developed [ISP]. This informational RFC is a status report of the current situation. Eight e-mail clients was selected to participate in the testing. Microsoft Outlook Express 5, Netscape Messenger 4.7 and Qualcomm Eudora Pro 4.2 because they are the most commonly used. Hotmail and Yahoo! Mail for the reason that they are web based. Pine for its text-based interface. Juno 4.05 [JUNO] was included since the developers showed interest in having Juno participating in the testing. KOM 2000 3 [KOM] is developed at Stockholm University and was therefore included. This document has been slightly revised by Jacob Palme. All such revisions are clearly marked with the markup: "(JP)". Jacob Palme takes responsibility for such revisions, while Hentze and Muto take responsibility for the other parts of this document. 2. Where to Find more Information and Comment on this Document More information, including the latest, possibly revised, version of this document can be found at http://dsv.su.se/jpalme/ietf/mhtml.html#implementation-status Information on how to join the mailing list, where you can comment on and discuss this document, can be found at http://dsv.su.se/jpalme/ietf/mhtml.html#mailing-list 3. Overview The main purpose of the MHTML standard is to allow HTML documents with inline graphics and other resources to be sent in a MIME multipart/related body part [REL]. The MHTML format can also be used for archiving a web page with all its content in one single MHTML file. MHTML also mentions the possibility of using MHTML for other formats than HTML, such as Portable Document format [PDF] and Virtual Reality Markup Language [VRML]. This paper, however, only looks at the use of MHTML for HTML formatted messages. MHTML messages are built up with a multipart/related structure, with objects included as MIME body parts. The objects can be images, sounds, applets etc. The objects are referenced in different ways, such as Content-IDs [MIDCID] and URL type URIs [URL]. 3.1 Example Example using Content-ID URL and Content-ID header to an embedded GIF picture: Message-ID: Date: Wed, 04 Apr 2000 04:01:00 +0200 From: MHTML MIME-Version: 1.0 To: mhtml-2@dsv.su.se Subject: A simple example Content-Type: multipart/related; boundary="==boundary-1"; type="text/html" Text displayed only to non-MIME-compliant mailers --==boundary-1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit ... text of the HTML document, which may contain a URI referencing a resource in another body part, for example through a statement such as: red test image --==boundary-1 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="red-test-image.gif" R0lGODlhdQAgAPcAAP//////zP//mf//Zv//M///AP/M///MzP/Mmf/MZv/MM//MA P+Z zP+Zmf+ZZv+ZM/+ZAP9m//9mzP9mmf9mZv9mM/9mAP8z//8zzP8zmf8zZv8zM/8zA P8A etc... --==boundary-1-- 4. Testing Methods To check whether the e-mail clients support the MHTML standard a number of different methods were used. 4.1 Methods of Producing MHTML Messages The e-mail clients' online help was used to determine their functions for producing and sending messages with HTML content. Methods common for applications in the given environment were also applied. 4.1.1 Submitting HTML Taken from the Web This function offers the user to send an existing web page on the Internet or on an intranet. The user needs only to enter the desired URL. The e-mail client inserts the web page content into the text area without the use of a browser. 4.1.2 Editing HTML with an Editor Provided for Writing E-mail Messages This function offers the user to create messages using HTML formatting features, such as bulleted lists, headers, colors and links, and inserting inline pictures, by using an editor included in the e-mail client. 4.1.3 Taking HTML From Files This function offers the user to select and copy HTML, including inline pictures, displayed in a browser. The displayed HTML is then inserted into the message with the paste command. 4.1.4 Options for Sending Mail with HTML When the user has created a message with HTML formatting, the e-mail clients offer different ways of sending it. Three methods are used: plain text only, HTML only and both plain text and HTML. 4.2 Correctness of Messages Sent by the Tested Clients To check the MHTML generated by the e-mail clients, six types (shown below) of test messages were sent. The generated messages were then manually analyzed in their plain text appearence. 4.2.1 Test Messages Generated by the E-mail Clients (a) This message contains basic HTML formatting, such as

. (b) This message includes images taken from the user's local hard disk inserted as inline pictures and background. (c) This message is similar to (b), but the images are taken from the web. (d) This message has the same content as (b) but is sent with the "both text and HTML" function. This generates a message with multipart/alternative [MIME2]. (e) This message includes images taken from a URL containing illegal characters. These characters should be encoded using one of the methods described in [MIME3], when the URL is in the Content-Location header. (f) This message includes images taken from a URL longer than 80 characters. Content-Location headers that exceed 80 characters should be folded using the algorithm in [URLBODY]. 4.2.2 Correct MHTML Correct MHTML requires that the e-mail clients generate MIME multipart structures according to the MHTML standard. The e-mail clients must not generate Content-Base headers (Content-Base was part of the first version of the MHTML proposed standard [MHTML97], but was removed in the second version in [MHTML99]). Illegal characters, that are inappropriate for an [RFC822] header, must be encoded. Content-Location URIs that exceed 80 characters must be folded. It is also of interest to determine how the e-mail clients use combinations of multipart/related and multipart/alternative to provide a choice between plain text and HTML rendition. 4.2.3 Link Types The MHTML standard specifies that body parts can be identified either by a Content-ID or by a Content-Location with an absolute [URL] or a relative URI [RELURL]. Test messages (a) to (f) were used to check how the e-mail clients produce links to reference body parts in a multipart/related structure. 4.2.4 Handling of Relative References When the HTML markup contains relative references the sending e-mail client must make sure that the references remain correct. This can be done by adding a element in the HTML markup or by altering the references in some way. 4.3 Test Messages for Receipt of MHTML To test the e-mail clients' receipt capability, fifteen different test messages with HTML content were sent to an SMTP-MTA [SMTP] using Telnet. These messages were then fetched by all tested e-mail clients. Each message tests whether the e-mail clients support receipt of an MHTML feature. These test messages are partly a revision of a set of test messages developed by Jacob Palme for the 1997 version of the MHTML proposed standard. The test messages can be found at http://www.dsv.su.se/jpalme/ietf/mhtml.html#testprogs 4.3.1 mhtml-1.txt Three body parts: one text/html, two inline GIFs, the inline GIFs have Content-Disposition. Uses Content-ID URLs to the inline GIFs. This message checks whether the e-mail clients can handle Content-ID URIs and Content-Type: multipart/related. 4.3.2 mhtml-2.txt Three body parts: one text/html, two inline GIFs. The inline GIFs have no Content-Disposition headers [CONDISP]. [MHTML99] says that Content-Disposition should be ignored within multipart/related, so this should not have any effect on rendering. Uses Content-ID URLs to the inline GIFs. This message checks whether the e-mail clients can handle messages without Content-Disposition headers. 4.3.3 mhtml-3.txt One text/html body part. Both images have to be retrieved using HTTP. Uses absolute URIs to the non embedded GIF pictures. This message checks whether the e-mail clients can retrieve objects using a URI specified protocol, such as HTTP. 4.3.4 mhtml-4.txt Two body parts: one text/html, one inline GIF. Uses Content-ID URL to the embedded inline GIF. One image is not included and has to be retrieved using HTTP. This message checks whether the e-mail clients can handle messages with different link types (Content-ID, Content-Location URIs). 4.3.5 mhtml-5.txt Three body parts: one text/html, two inline GIFs. Uses absolute URIs to the embedded GIFs. One image has an absolute Content-Location, one has a relative Content-Location. This message checks whether the e-mail clients support Content- Location with absolute URIs for links between body parts. 4.3.6 mhtml-6.txt Two body parts: one text/html, one inline GIF. The relative URI is resolved without an explicit base available. This message checks whether the e-mail clients support Content- Location with relative URIs with no explicit base available. 4.3.7 mhtml-7.txt Three body parts: one text/html, two inline GIFs. Uses relative URIs to the inline GIF pictures. Uses a Content-Location header in the multipart/related heading as a base. One image must be retrieved using HTTP. One image has a relative Content-Location that must be resolved by BASE specified in the multipart/related Content-Location header. One image has an absolute Content-Location. This message checks whether the e-mail clients support Content- Location with relative URIs, which are resolved to absolute URIs through base indicated in a Content-Location in a surrounding multipart content heading. 4.3.8 mhtml-8.txt Three body parts: one text/html, two inline GIFs. Uses relative URIs to embedded GIF pictures. A Content-Location header in the text/html heading will be a BASE to all relative URIs. The embedded GIF pictures have absolute Content-Location headers. This message checks whether the e-mail clients support Content- Location header to indicate a base to be used for other URIs in the same content body. 4.3.9 mhtml-9.txt A multipart/mixed [MIME2], which contains two body parts. One of type multipart/related with one text/html part and two inline GIF pictures. The other of type text/html where the images are not included and have to be retrieved using HTTP. Uses relative URIs to the inline GIF pictures. In the first multipart/related the two inline GIF pictures are embedded. One image has an absolute Content- Location. One has a relative Content-Location which must be recursively resolved using the BASE specified in the multipart/mixed heading. This message checks whether the e-mail clients support Content- Location header on a multipart body to apply recursively to included body parts. 4.3.10 mhtml-10.txt Three body parts: one text/html, two inline GIFs. Uses relative URIs to the inline GIF pictures. One image has a relative Content- Location, one has an absolute Content-Location. One image must be retrieved using HTTP. The relative Content-Location is resolved by in the HTML markup. This message checks whether the e-mail clients support use of the HTML element for resolution of relative URIs. 4.3.11 mhtml-11.mime A multipart/mixed, which contains two body parts: each of type multipart/related. In the first multipart/related part the reference is of the absolute URI kind with absolute Content-Location. The other multipart/related part has a reference of the Content-ID type. This message checks if the e-mail clients support more than one multipart/related in the same e-mail message. 4.3.12 mhtml-12.txt Four body parts: one text/plain, one text/html, two inline GIFs. Uses relative URIs to the embedded GIF pictures. Uses multipart/alternative inside multipart/related to provide a choice between a plain text and HTML rendition. This message checks if the e-mail clients support combination of multipart/related with multipart/alternative, with multipart/alternative outside the multipart/related. 4.3.13 mhtml-13.txt Four body parts: one text/plain, one text/html, two inline GIFs. Uses relative URIs to the embedded GIF pictures. Uses multipart/alternative outside multipart/related to provide a choice between plain text and multipart/related. This message checks if the e-mail clients support combination of multipart/related with multipart/alternative, with multipart/alternative inside the multipart/related as the start body part of the multipart/related. 4.3.14 mhtml-14.txt Three body parts: one text/html, two inline GIFs. Uses relative URIs to the embedded GIF pictures. The URI in Content-Location is folded. One image must be retrieved using HTTP, one image has an absolute Content-Location, one image has a relative Content-Location that must be resolved by base specified in the multipart/related Content- Location heading. This message checks if the e-mail clients support unfolding of received URIs in MIME header fields. 4.3.15 mhtml-15.txt Three body parts: one text/html, two inline GIFs. Uses relative URIs to the inline GIF pictures. The Content-Location contains illegal, non-ASCII characters. One image must be retrieved using HTTP, one image has an absolute Content-Location and one image has a relative Content-Location that must be resolved by the BASE specified in the multipart/related Content-Location heading. This message checks if the e-mail clients support decoding of received URIs in MIME header fields. 4.4 Pairwise Compatibility To check how the e-mail clients included in our test handles messages sent from one and received by another mail client, messages were generated and sent to all the other e-mail clients. Outlook Express, Netscape Messenger, Eudora Pro and Yahoo! Mail can generate messages with HTML content, the other ones cannot generate MHTML but are still tested for receipt capability. The following messages were sent: (a) Message with HTML formatting, such as headers, links and bulleted lists. (b) Message with inline pictures and non-ASCII characters. 4.5 In-out Testing When a user receives an e-mail message and wants to re-send it there are a number of ways of doing this. The most common ways are by commands such as "reply" and "forward". Some e-mail clients also have a function called "resend" that sends the message more or less unaltered. These functions can cause problems and as a consequence generate inaccurate MHTML messages. The test was made by sending a basic MHTML message to all the e-mail clients. The multipart/related message contains a text/html part and two GIF pictures, included as bodyparts. The images are referenced with links of the Content-ID kind. The messages were opened in each e-mail client and re-sent using the commands available, and then analyzed in an application which displays files as plain text. 5. Testing Results 5.1 Testing for receipt of MHTML This table presents a summary of the results on receipt of the fifteen test messages described in section 4.3. The test results are described further in Appendix A. Outl Mess Eudo Pine Hotm Yaho KOM Juno Version 5.0 4.7 4.2 4.20 (1) (1) 3.0 4.05 Content-Type: Yes Yes Yes Yes Yes Yes Yes Yes multipart/related (mhtml-1.txt). Content-ID (mhtml-1.txt). Yes Yes Yes Yes Yes Yes Yes Yes Messages without Yes Yes Yes Yes Yes Yes Yes Yes Content-Disposition Yes headers (mhtml-2.txt). Retrieve using HTTP Yes Yes Yes No Yes Yes Yes Yes (mhtml-3.txt). (2) Different link types in Yes Yes Yes No Yes Yes Yes Yes the same message (2) (mhtml-4.txt). Content-Location with Yes Yes Yes Yes No Yes Yes Yes absolute URIs for links (3) between body parts (mhtml-5.txt). Content-Location with Yes No No Yes Yes No No Yes relative URIs with no explicit base available (mhtml-6.txt). Content-Location with Yes No No Yes No No Yes Yes relative URIs, which are (3) (2) (4) resolved to absolute URIs through base indicated in a Content-Location in a surrounding multipart content heading (mhtml-7.txt). Content-Location header to Yes Yes No Yes No No No Yes indicate a base to be used for other URIs in the same content body (mhtml-8.txt). Content-Location header on Yes No No Yes No No No Yes a multipart body to apply (5) (4), (2) (4) recursively to included (5) body parts (mhtml-9.txt). Use of the HTML Yes Yes Yes Yes No Yes Yes Yes element for resolution of (6) (2) relative URIs (mhtml-10.txt). More than one Yes Yes Yes Yes No Yes Yes No multipart/related in the same e-mail message (mhtml-11.txt). Combination of Yes No No Yes Yes No No Yes multipart/related with (JP: (JP: multipart/alternative, Yes No) with multipart/alternative on inside the Mac) multipart/related (mhtml-12.txt), relative URLs for links to images. Combination of Yes No No Yes No No No Yes multipart/related with (JP: (JP: multipart/alternative, Yes Yes) with multipart/alternative on outside the Mac) multipart/related (mhtml-13.txt), relative URLs for links to images. Unfolding of received URIs Yes No No Yes Yes No Yes Yes in MIME header fields (4), (2) (4), (4) (mhtml-14.txt). (5) (5) Decoding of received URIs Yes Yes No Yes Yes No Yes Yes in MIME header fields (4) (4), (2) (4), (4) (4) (mhtml-15.txt). (6) (5) (1) Tested in April 2000 (2) Pine cannot retrieve objects using HTTP (3) But handles absolute Content-Locations correctly (4) Not when retrieving using HTTP (5) But cannot handle absolute Content-Locations correctly (6) But cannot handle relative Content-Locations correctly 5.1.1 Additional tests made June 2000 by Jacob Palme (JP) These additional tests were made on a Macintosh, using Netscape Messenger 4.7 and Eudora 4.2.1 Macintosh version. Note that for Eudora, the Macintosh version uses a different code base than the Windows version. Mess Eudo Hotm KOM Combination of Yes No No Yes multipart/related with multipart/alternative, with multipart/alternative inside the multipart/related (mhtml-16.txt), Content-ID- links to images. Combination of Yes Yes Yes Yes multipart/related with multipart/alternative, with multipart/alternative outside the multipart/related (mhtml-17.txt), Content-ID- links to images. 5.2 Testing for submission of MHTML This table presents a summary of the testing of the e-mail clients' possibilities of generating and sending MHTML messages. The test results are described further in Appendix A. Outl Mess Eudo Pine Juno Hotm Yaho KOM Version 5.0 4.7 4.2 4.20 4.05 (1) (1) 3.0 Provides an editor for Yes Yes Yes No No No Yes No composing HTML formatted messages Send a web page, user Yes Yes No - - - No - gives URL (2) Yes Copy HTML formatted text Yes Yes Yes Yes Yes Yes Yes Yes and paste it into the message Copy displayed HTML with No No No - - - No - inline pictures, and paste it into the message Sending messages as plain Yes Yes Yes Yes Yes Yes Yes Yes text only Sending messages as HTML No Yes Yes - - - No Yes only Sending messages as both Yes Yes Yes - - Yes Yes No plain text and HTML (3) Create a structure with a Yes No Yes - - Yes No - multipart/alternative inside a multipart/related Create a structure with a No Yes No - - No No - multipart/related inside a multipart/alternative Links of the Content-ID Yes Yes Yes - - Yes No No kind (3) Links of the Yes No No - - No No No Content-Location kind Illegal characters in MIME Yes - - - - - - - headers coded correctly Folding of long URIs in No - - - - - - - MIME headers Inline pictures included Yes Yes Yes - - Yes No - as bodyparts - Indicates that the tested function is not applicable. (1) Tested in April 2000. (2) The web page is sent as an attachment. (3) When sending using Hotmail's stationaries. 6. Conclusions Our results show that most of the tested MHTML functions are supported by the tested e-mail clients, but different functions are supported by different clients. Some clients especially lack in sending capabilities, but can receive and display most MHTML features. One common problem is references of the Content-Location kind. None of the tested e-mail clients can recursively resolve URIs fully correct. Only two can resolve Content-Locations with relative URIs through base indicated in a Content-Location in the surrounding multipart heading. 4 of 8 handle Content-Location with relative URIs with no explicit base available correctly. 4 of 8 can understand a Content-Location header as a base for other URIs in the same content body. All tested clients support absolute Content-Locations with absolute URIs for links between body parts. All except one support relative Content-Locations with absolute URIs. We suggest that the problems concerning Content-Location references are taken into account in the next version of the MHTML standard. Only one of the tested e-mail clients produces Content-Location when sending MHTML. This may imply that the function should be removed from the standard. Since none of the other e-mail clients produce Content-Location, it has been hard to analyze how long URLs and URLs containing illegal characters are handled. More e-mail clients must produce Content-Location URLs to make it possible to determine whether these two functions should remain as a part of the MHTML standard. The web based e-mail clients have limited possibilities for constructing a suitable user interface for generating MHTML. This is a consequence of the difficulties in using HTTP/HTML for this purpose. Some of the test messages sent are a bit unrealistic and would never be generated by an e-mail client. All the messages generated by the tested e-mail clients were less complex in their composition which gave better results. The final conclusion is that the MHTML standard is not yet without changes ready to be elevated to the next level in the Internet Standards Track. To advance to that level the MHTML standard must be revised and/or more features must be added to the e-mail clients. 7. Acknowledgments Lars Enderin, Fredrik Kilander, Jacob Palme and Bill Phelan. 8. Security Considerations The e-mail clients sometimes ignore parts of the content in a MHTML message, without notifying the receiver. This may mislead the receiver to believe that the displayed content is all there is. For other Security Considerations related to the use of the MHTML standard we refer to the referenced documents. 9. References [CONDISP] R. Troost, S. Dorner: "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995. [ISP] S. Bradner: "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [JUNO] Further information about Juno can be found at http://www.juno.com. [KOM] Further information about KOM 2000 can be found at http://cmc.dsv.su.se/KOM2000. [MHTML97] J. Palme, A. Hopmann: MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML), RFC 2110, March 1997. [MHTML99] J. Palme, A. Hopmann, N. Shellnes: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML), RFC 2557, March 1999. [MIDCID] E. Levinson: "Content-ID and Message-ID Uniform Resource Locators". RFC 2111, February 1997. [MIME-IMB] N. Freed & N. Borenstein: "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies". RFC 2045, November 1996. [MIME1] N. Borenstein & N. Freed: "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Sept 1993. [MIME2] N. Borenstein & N. Freed: "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types". RFC 2046, November 1996. [MIME3] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, December 1996. [PDF] T. Bienz, R. Cohn and J. Meehan: "Portable Document Format Reference Manual, Version 1.1", Adobe Systems Inc. [REL] E. Levinson: "The MIME Multipart/Related Content-Type". RFC 2112, February 1997. [RELURL] R. Fielding: "Relative Uniform Resource Locators", RFC 1808, June 1995. [RFC822] D. Crocker: "Standard for the format of ARPA Internet text messages." STD 11, RFC 822, August 1982. [SMTP] J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [URL] T. Berners-Lee, L. Masinter, M. McCahill: "Uniform Resource Locators (URL)", RFC 1738, December 1994. [URLBODY] N. Freed and Keith Moore: "Definition of the URL MIME External-Body Access-Type", RFC 2017, October 1996. [VRML] G. Bell, A. Parisi, M. Pesce: "Virtual Reality Modeling Language (VRML) Version 1.0 Language Specification." May 1995, http://www.vrml.org/Specifications/. 10. Authors' Addresses Rickard Hentze Phone: +46-8-648 23 27 Lackovagen 25 Fax: +46-8-598 332 98 S-121 50 Johanneshov, Sweden Email: rickard@hentze.com Aiko Muto Phone: +46-8-779 46 51 Kungsklippevagen 3 Fax: +46-8-779 46 52 S-141 40 Huddinge, Sweden Email: aikomuto@hotmail.com Revisions marked "(JP)" of this document from June 2000 are done by: Jacob Palme Phone: +46-8-16 16 67 Skeppargatan 73 Fax: +46-8-783 08 29 S-115 30 Stockholm, Sweden Email: jpalme@dsv.su.se 11. Full Copyright Statement "Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 12. Appendix A - More Detailed Testing Results 12.1 Microsoft Outlook Express Microsoft Outlook Express version 5.01 was tested in Windows NT 4 operating system. 12.1.1 Methods of producing MHTML messages Outlook Express offers different ways of producing MHTML messages. It provides an editor for writing e-mail messages in HTML format. The generated HTML markup can be edited by selecting the "Source" tab. To send a web page the user selects "Message/New Message Using/Web page...". This opens a dialog box where the user enters the URL of the web page to be sent. In the HTML editor the user can insert copied HTML with the "paste" command. Background images or colors, if any, are not included when pasting. Outlook Express offers two ways of sending messages. The user can choose between two different mail sending formats, "Plain text" or "HTML". The latter produces a message with two versions of the content to provide a plain text alternative for e-mail clients that cannot read HTML. 12.1.2 Correctness of Messages Sent Outlook Express always sends two versions of the message content when the user has chosen it to be sent in HTML. It sends a multipart/related with the parameter "type=alternative". The start body part is a multipart/alternative that contains a text/plain part and a text/html part. The other body parts in the multipart/related are of the image/gif kind. Outlook Express uses links of the Content-ID kind between body parts when the images are taken from the user's local hard disk. Links to images taken from the web are of the absolute URI kind with absolute Content-Locations. It is not possible to use an image taken from the web as background in a message. Illegal characters in the MIME headers are correctly coded. URIs over 80 characters are not folded. The inline pictures are included as body parts in the multipart/related, but not in message (e). When the user sends a web page the e-mail client adds a element in the HTML markup. This implies that all relative URIs remain correct. 12.1.3 Receipt of MHTML messages Outlook Express supports Content-Type: multipart/related when sending and receiving MHTML. It supports combination of multipart/related with multipart/alternative, with multipart/alternative outside the multipart/related. Outlook also supports a structure with multipart/alternative inside the multipart/related. The following MHTML features are supported: - Content-ID - Messages without Content-Disposition headers - Retrieve using HTTP - Different link types in the same message - Content-Location with absolute URIs for links between body parts - Content-Location with relative URIs with no explicit base available - Content-Location with relative URIs, which are resolved to absolute URIs through base indicated in a Content-Location in a surrounding multipart content heading - Content-Location header to indicate a base to be used for other URIs in the same content body - Content-Location header on a multipart body to apply recursively to included body parts - Use of the HTML element for resolution of relative URIs - More than one multipart/related in the same e-mail message - Unfolding of received URIs in MIME header fields - Decoding of received URIs in MIME header fields 12.1.4 Pairwise compatibility Outlook has no problems receiving and showing what the other tested e-mail clients send. It showed all messages sent from Messenger, Eudora Pro and Yahoo! Mail correctly. 12.1.5 In-out testing Outlook Express offers two different ways of re-sending a message. When the user selects "reply" the message is sent back as it is together with a plain text version. The message is sent as a multipart/related with the parameter "type=multipart/alternative". The start body part is multipart/alternative containing a text/plain and a text/html body part. In the text/html part Outlook adds a couple of html elements, such as ,