ࡱ > @ R jbjb 3 h h l " " " , X X X 8 T 4 Q T P f ( w ' G* d Q Q Q Q Q Q Q , +T KV Q X + U " w + + Q : P : : : + X Q : l X X 8 X X + Q : : @ L ' h X O ;W e3 T O 6 O Q Q JO 6 /W : /W O : Network Working Group Yvonne Backhans Draft Tina Hekkala Category: Informational Stockholm University/KTH draft-ietf-hekkala-backhans-mhtml February 2004 Expires August 2004 Examining, implementing and testing of RFC2557 (MHTML) Status of this Document This document provides information for the Internet community. This document does not specify an Internet standard of any kind. Distribution of this document is unlimited. Copyright (C) The Internet Society 2004. All Rights Reserved. Abstract In order to send a web page with all or some referenced resources in an e-mail message, the web page and its resources need to be aggregated in a MIME formatted structure. The receiver of such a message need to know how to unpack the structure to display the web page as an email message. The standard RFC2557, MIME Encapsulation of aggregate documents, such as HTML (MHTML) specifies methods for achieving this. The purpose of this document is to examine RFC2557 and implement an e-mail client that sends MHTML using the Content-Location MIME header field, specified in RFC2557, for referencing resources. The e-mail client has been used to send MHTML messages to five commercial e-mail clients to see if they can display such messages. The conclusions drawn from our tests show that all, except one, of the tested e-mail clients can correctly display the simplest form of MHTML messages using Content-Location. This document can be downloaded in plain text, Microsoft Word and PDF formats from http://dsv.su.se/jpalme/ietf/mhtml.html#testprogs. The PDF version is a little more neatly formatted than the plan text version, but the content is the same. Table of Contents TOC \o "1-2" \n 1. Introduction 2. MHTMLMailer an implementation of RFC2557 2.1 Overview 2.2 The structure of a MHTML message 2.3 Sending MHTML - requirements in RFC2557 3. Comparison of MHTMLMailer with Microsoft Outlook Express, version 6 3.1 Testing 3.2 Test results 3.3 Summary - differences between Microsoft Outlook Express and MHTMLMailer 4. Testing and results 4.1 Receipt of MHTML messages 4.2 Test results 5. Comments on RFC2557 5.1 The purpose of developing RFC2557 should be clearer 5.2 Badly organized and formulated text 5.3 Techniques that should not or can not be used 5.4 How to view the Content-Location header 5.5 Techniques more difficult than necessary 6. Acknowledgments 7. References 8. Author's Addresses Introduction MHTML (as specified in RFC2557) was developed in order to facilitate sending HTML or other multi-resource documents in e-mail (via SMTP). MHTML is a way of aggregating a multi-resource document in one single file by embedding the files that make up the multi-resource document in a MIME multipart/related structure. This format may also be used for archiving multi-resource documents or retrieving such documents via protocols other than SMTP (for example HTTP or FTP). The purpose of this report is to examine RFC2557 and implement an e-mail client (called MHTMLMailer) that sends MHTML using the Content-Location MIME header field, specified in RFC2557, for referencing resources. The mailer has then been used to send MHTML messages to five commercial e-mail clients to see how well they can display such messages. The goal was to develop a mailer that is unconditionally compliant with RFC2557 and that our work would aid IETF in their work to revalue the status of RFC2557 and examine whether the MHTML standard can be elevated from the proposed standard level to the draft standard level in the Internet Standards Track. MHTMLMailer an implementation of RFC2557 Overview The mailer that was implemented using JavaMail API, for the purpose of sending MHTML using a Content-Location header, consists of two Java classes. The classes are called MHTMLCreator and MHTMLSender. MhtmlCreator takes the HTML source code of the web page, looks for referenced objects such as images and style sheets, retrieves them, and creates body parts of all objects. This is achieved by creating instances of the JavaMail class MimeBodyPart. An instance of MhtmlSender is then created which assembles the MimeBodyParts into an e-mail message, having the media type multipart/related, and sends it. The structure of a MHTML message We use the terms MHTML message and multipart/related structure as synonyms for a MIME-encoded multi-resource document. Figures 2.1 and 2.2 show the logical and real structure of a MHTML message created by our mailer, MHTMLMailer. Figure 2.1 does not show all the headers in the MIME parts but focuses on the relations between the different parts by marking the references in bold type. Figure 2.2 shows what the MHTML message looks like as plain text. Figure 2.1 The message in this example is made up of three body parts: an HTML file, a jpg image and a gif image. The HTML file and the two referenced image files are embedded in a structure with the media type multipart/related. The media type is shown in the Content-Type header field in the heading of the e-mail. Apart from the value of the field being multipart/related the Content-Type header field also has two parameters, type and boundary. The type parameter specifies the media type of the multipart/related start object. The boundary parameter is a string of arbitrary US-ASCII characters. The string is used to separate the different body parts in the multipart/related structure. [RFC2557] This string can be seen in figure 2.2. The body parts of the MHTML message are located in the body of the e-mail (the body is separated from the heading by an empty line (CRLFCRLF)). Every body part has its own header and a body. Each header has a Content-Type header field specifying the media type of that body part. The Content-Type field in the body part containing the HTML file also has a charset parameter specifying the character set of the web page. In the header of each body part (apart from the text/html body part) there is a Content-Location header field. The value of this field is an URI which is used to locate the object by the referring HTML file. The heading of the e-mail also has a Content-Location field specifying an URI that can be used as a reference to the MHTML message. [RFC2557] To: yvonne-b@dsv.su.se From: tina-hek@dsv.su.se Subject: Ett mhtmlmeddelande Mime-Version: 1.0 Content-Type: multipart/related; type="text/html"; boundary="This_Is_A_unique_boundary " Content-Location: http://www.dsv.su.se/~yvonne-b/aggregate.mhtml -- This_Is_A_unique_boundary Content-Type: Text/html;charset="US-ASCII" Content-Transfer-Encoding: 7bit
elements next to the image. These URIs are distorted by Hotmail into a strange absolute URI. (The only exceptions are relative URIs, containing no illegal characters, that are shorter than 78 characters). This implies that the HTML code has also been changed. Since messages cannot be saved as text in Hotmail this has not further been explored. There is no difference between how Hotmail displays the message if there is a base URI in the Content-Location header field in the heading of the message or if there is not. Hotmail can both decode and unfold URIs in Content-Location header fields. Yahoo! Mail Yahoo! Mail was tested with operating system Windows 2000 using Internet Explorer 6 and Netscape 7.01 as browsers. Yahoo! Mail does not show the web page as it looks on the web. No images are displayed and the linked style sheet is not used. The images are displayed as attachments. This means that Yahoo cannot handle MHTML at all. When the images are returned to their place on the web the images with an absolute URI are displayed correctly which means that Yahoo retrieves these images via HTTP. Whether Yahoo can decode and unfold URIs in Content-Location header fields cannot be tested since Yahoo does not handle Content-Location on receipt. Possible source of error Images removed from the web Since the testing of all e-mail clients were done in the same physical location we tried to avoid that images would be retrieved from a cache by using different images for different web pages and by removing these images from the web prior to opening the MHTML messages the first time. The Refresh or Reload function in the e-mail client has been used throughout to update the messages. Unfolding of folded URIs The method we use to fold URIs may not be the best method to fold Content-Location header field values. Our method entails folding URIs after 40 characters which means that they can be folded anywhere in the string of characters, even in the middle of the file name. This manner of folding a field value is not recommended in RFC2822. Conclusions The conclusions from these tests are that most of the tested e-mail clients can handle Content-Location. All of them, with the exception of Yahoo, can display MHTML messages sent by MHTMLMailer more or less without errors. Eudora cannot show images referenced by absolute URIs and Netscape cannot handle a base URI in the Content-Location header field in the heading of the message. It is difficult for us to comment on why these e-mail clients can handle one function but not another although the functions require the same treatment. All e-mail clients that can handle MHTML with Content-Location can decode URIs with the exception of Eudora. Concerning encoding there was no difference whether the URI contained only space or illegal characters (, , ). Of the e-mail clients that can handle MHTML with Content-Location, Outlook Express and Hotmail can unfold folded URIs while Eudora and Netscape cannot. Comments on RFC2557 The specification of how to implement the Content-Location header is not always straightforward. We found several issues that were unclear and sometimes even contradictory. In this chapter, we summarize the different parts of the standard that were problematic when interpreting and implementing the mailer. A general comment on RFC2557 is that it could be a lot clearer concerning the purpose of having two ways of referencing MIME body parts in a multipart/related structure. Also the thoughts behind developing the standard could be clearly pointed out. We think that maybe the authors have tried to make the standard "too general" and that this sometimes contributes to making it ambiguous. The purpose of developing RFC2557 should be clearer MUST and SHOULD requirements are neither adequate nor clear Multipart/related The MIME media type multipart/related is used to aggregate the different parts of a document. RFC2557 mentions no other means of aggregating the referenced objects of an HTML document, and yet the requirement to use multipart/related is a SHOULD requirement. Why? Is not the main purpose of RFC2557 to embed referenced objects in a multipart/related structure? Encoding and folding Encoding of URIs containing illegal characters and folding of long URIs are not subject to any SHOULD or MUST requirement. It is unclear why. When implementing our mailer we choose to view these as "real" requirements. The reason for not specifying the requirements with capital letters might be the authours wishes to be able to implement MHTML when sending via protocols other than SMTP. If this is the reason it should be mentioned in RFC2557. Charset parameter Four different requirements concerning use of the correct charset parameter, are formulated in RFC2557 (chapter 4.4.1 and 4.4.2). This makes the charset parameter seem very important (especially in relation to encoding and folding). The requirements are not well formulated and leave the implementor wondering how they should be managed. Content-Location and MICs The last part of chapter one mentions, as a reason for using the Content-Location header, that you are able to send MHTML without rewriting the HTML, the disadvantage with such rewriting being that "security checksums" cannot be validated. This is, of course, dependent on when MICs are derived. RFC2557 gives the impression that the validation only concerns the web page (the text/html part of the MHTML message) compared to the web page residing on the web. Such a validation might be impossible for other reasons: the sender might not have sent the URI to the web page in the MHTML message since there is no requirement to do so. Another reason might be that line breaks might need to be replaced as described in chapter 10. If the sender, on the other hand, puts her signature on the entire MHTML message after composing it, there is no special advantage of using Content-Location with regards to security checksum validation. This, of course, requires that the receiver does trust the sender. Our point is that we find that RFC2557 exaggerates the use of Content-Location for security reasons. Not needing to rewrite URIs is an advantage on its own. Badly organized and formulated text Title related to content of chapters Our general impression of the disposition in RFC2557 is that it is not very organized but rather messy. The content related to the titles of some chapters can be questioned and the reader is confused about the matters handled. Below are some examples of confusing disposition. Chapter four: Encoding of MIME header fields? Chapter four is entitled "Encoding of MIME header fields" but it seems to specify the encoding of the text/html body part. This is because it deals with the charset parameter that is not used when encoding header fields but when encoding text/html data. Chapter seven: Use of the Content-type multipart/related? Chapter seven is entitled "Use of the Content-type multipart/related". The first part is fine with a description of how to use multipart/related, what requirements there are and so on. Then, out of nowhere, there is a listing of the advantages of MHTML. We think this information would be better suited as an introduction to the standard. After the listing of the advantages there is a passage that we misunderstood for a long time and that even now seems odd. The passage is: "When a sending MUA sends objects which were retrieved from the WWW, it SHOULD maintain their WWW URIs. It SHOULD not transform these URIs into some other URI form prior to transmitting them. This will allow the receiving MUA to both verify MICs included with the message, as well as verify the documents against the WWW counterpoints, if this is appropriate." Since the text is placed in a chapter entitled "Use of the Content-type multipart/related" it is not obvious that the requirement only deals with the text/html body part. We interpret this text as when sending HTML documents as MHTML one should not rewrite the HTML source code. If this is a correct interpretation then the implication of this is that one should always use the Content-Location header and never use the Content-ID header. Again, if this is correct then it could be specified in a better way for example by saying: When sending web pages taken from the web one should always use the Content-Location header field in the multipart/related structure, in order to be able to send the web page without rewriting the URIs in the HTML source. This motivation for using Content-Location is in our meaning not a very good one, as discussed in the chapter "Content-Location and MICs" above. Should URIs in Content-Location field follow the URI syntax or not? Chapter 4 contains the following subchapter: 4.4.1 Encoding of URIs containing inappropriate characters Some documents may contain URIs with characters that are inappropriate for an RFC 822 header, either because the URI itself has an incorrect syntax according to [URL] or the URI syntax standard has been changed to allow characters not previously allowed in MIME headers. These URIs cannot be sent directly in a message header. If such a URI occurs, all spaces and other illegal characters in it must be encoded using one of the methods described in [MIME3] section 4. The text above allows URIs with illegal syntax to be sent in MHTML messages while the ABNF specification of the Content-Location header field in chapter 4.1 says the URI should follow the syntax for URIs. We think it should be clearly motivated if URIs with illegal syntax is allowed or not. Terminology HTML aggregate objects Chapter 2.2 (Other Terminology) defines terms that are never used again. An example is HTML aggregate objects. Aggregate document Another term whose meaning is unclear is "aggregate document". Does it mean a web page with all referenced objects or a MHTML message? The title of the standard is MIME encapsulation of aggregate documents, such as HTML (MHTML). This implies that the web page (HTML) is the aggregate document. Then in chapter three there is the following passage: "An aggregate document is a MIME-encoded message that contains a root resource (object) as well as other resources linked to it via URIs." This on the other hand makes it sound as if an aggregate document is a MHTML message, which in turn makes the title of RFC2557 ambiguous. In chapter seven the text/html MIME part is referred to as a "root resource of the aggregate document". Chapter 4.3 entitled "URIs of MHTML aggregates", where MHTML aggregate is solely used in this chapter and is not defined in the terminology chapter. Aggregate document, MHTML aggregate, multipart/related structure and MHTML multipart/related structure are probably used as synonyms. None of these terms are defined in the terminology chapter. Sometimes, the word "message" is used in a strange way. Chapter seven begins: "If a message contains one or more MIME body parts containing URIs and also contains as separate body parts, resources, to which these URIs (as defined, for example, in HTML 2.0 [HTML2]) refer, then this whole set of body parts (referring body parts and referred-to body parts) SHOULD be sent within a multipart/related structure as defined in [REL]." It sounds a bit odd that a message contains body parts since it is not a message before putting it in a multipart/related structure and sending it. We recommend checking the terminology in RFC2557 to reduce the number of terms used and to define every important term. The standard should also be checked concerning semantics and editorial errors that, unnecessarily, confuse the reader. Also, a definition of MHTML should be added. Editorial errors? Another peculiar passage is found in chapter 4.4.1 that states reasons for encoding URIs in Content-Location headers: "...either because the URI itself has an incorrect syntax according to [URL] or the URI syntax standard has been changed to allow characters not previously allowed in MIME headers." The word "previously" should not be present. We assume that the meaning is to encode characters that are not allowed in MIME header fields regardless whether these previously where not allowed in URIs. The text continues: "These URIs cannot be sent directly in a message header. If such a URI occurs, all spaces and other illegal characters in it must be encoded using one of the methods described in [MIME3] section 4. Receiving clients MUST decode the [MIME3] encoding in the heading before comparing URIs in body text to URIs in Content-Location headers." The first sentence concerns only message headers. The latter sentence makes it clear that also headers of MIME parts should be encoded (or else it would be unnecessary to decode these). In other parts of RFC2557 there is a clear distinction between the message heading and the headers of MIME parts so the reader is left wondering whether to encode all or only message headers. Techniques that should not or can not be used Unknown-8bit Chapter 4.4.1 specifies: "The charset parameter value "US-ASCII" SHOULD be used if the URI contains no octets outside of the 7-bit range. If such octets are present, the correct charset parameter value (derived e.g. from information about the HTML document the URI was found in) SHOULD be used. If this cannot be safely established, the value "UNKNOWN-8BIT" [RFC 1428] MUST be used." We have identified two problems concerning the above specification: RFC1428 referred-to by the MUST requirement above, is an informational RFC and does not participate in the standards track.Normative references (like MUST requirements) must refer to standards on a higher level than the referring standard or else the referring standard cannot advance in the standards track [RFC3160]. Is UNKNOWN-8bit really meant to be used like this?The appendix of RFC1428 says:"This character set is not intended to be used by mail composers. It is assumed that the mail composer knows the character set in use and will mark it with a character set value The use of the "unknown-8bit" label is intended only by mail gateway agents which cannot determine via out-of-band information the intended character set." One could draw the conclusion that "UNKNOWN-8BIT" should not be used when implementing an e-mail client. There is no explanation for this requirement in RFC2557 and we think there should be a motivation why this is a requirement that MUST be met. Folding of long URIs in Content-Location headers The following is what RFC2557 says about folding: "Since MIME header fields have a limited length and long URIs can result in Content-Location headers that exceed this length, Content-Location headers may have to be folded. Encoding as discussed in clause 4.4.1 MUST be done before such folding. After that, the folding can be done, using the algorithm defined in [URLBODY] section 3.1." [RFC2557] The method of encoding that RFC2557 specifies states that encoded fields cannot be longer than 75 characters, and if they are they will be folded. We assume that this means that no other folding (as specified in RFC2557) should be needed. It should not be necessary to fold an encoded URI as specified in the last sentence of the passage. Only when there is an URI that does not need to be encoded but needs to be folded, would you need to do a separate folding. The referred-to standard RFC2017 (URLBODY), can not be applied on an URI in a Content-Location header field. We give our analysis of why this is so, next. RFC2017 - Definition of the URL MIME External-Body Access-Type This standard specifies a MIME part having the media type "message/external-body" that can be referred to by URIs. The purpose of message/external-body is to have a way of NOT sending the object referred-to. [MIME2] Which is exactly the opposite of the purpose of RFC2557, which seems odd. In RFC2017, the algorithm to fold URIs is intended to be used to fold a parameter to a Content-Type field with the value message/external-body. The value of the parameter is in this case an URI as it is in a Content-Location header field. [RFC2017] But that seems to be the only similarity. Before the algorithm in RFC2017 is specified, the authors state the following: "The syntax of an actual URL string is given in RFC 1738. URL strings can be of any length and can contain arbitrary character content. This presents problems when URLs are embedded in MIME body part headers that are wrapped according to RFC 822 rules. For this reason they are transformed into a URL-parameter for inclusion in a message/external-body content-type specification as follows:" Our impression is that the authors have identified problems with sending URIs in MIME header fields and consequently solves the problems by putting the URIs in a parameter to the Content-Type field. We have not made any efforts to find out exactly what the problems, identified by the authors of RFC2017, are nor why the problem is solved when sending the URI in a parameter. This is an issue for the authors of RFC2557 to deal with. We just thought it would be worth mentioning since if there is a problem then this problem also concerns the Content-Location header. The algorithm in RFC2017, referred by RFC2557 The first step is to encode illegal characters according to RFC2396 [RFC2017], but this is not in line with what RFC2557 specifies since RFC2557 states to encode illegal characters according to RFC2047. If an implementor would encode according to what RFC2017 specifies this would mean that the receiver of such a message would not be able to match Content-Locations to the URIs in the HTML source code, since RFC2557 specifies not to decode characters encoded according to RFC2396 before matching the URIs. The next step is to fold the URI in strings that are 40 characters or less. This step is not a problem in itself. The third step is to put the strings separated by LWSP between quotation marks in an URL parameter to a Content-Type field with the value message/external-body. LWSP is, if we are correct, the opposite of FWSP and FWSP allows folding but LSWP does not. If this is true then this method does not even fold the URI. One commentator on the mhtml mailing list wrote that RFC2231 deals with specific methods for folding and encoding a parameter to a Content-Type field. We have choosed not to investigate this since RFC2557 has nothing to do with parameters in Content-Type header fields but Content-Location header fields without parameters. So, how should folding be implemented? How the algorithm in RFC2017 is supposed to be applied to a Content-Location header field is not known to us. Nor is it clear why RFC2557 refers to RFC2017 instead of RFC2822. We think RFC2822 should be applied, given that Content-Location fields are also in a sense RFC2822 fields. It is then unclear how to fold URIs in Content-Location fields. According to the definition of Content-Location, FWS can only be used before or after the URI. This would mean that if an URI makes the Content-Location field longer than 78 characters (following the SHOULD requirement of RFC2822) you cannot fold it to make the line shorter. We will not dig any deeper into this matter, the purpose is to present the problems we have had in implementing RFC2557. It is up to the authors to specify how to fold so implementors easily can follow the specification. Use of Thismessage:/ We have not been able to see the point in using "thismessage:/", as specified in RFC2557, to resolve relative URIs when a MHTML message has no base URI in the Content-Location field in the heading. What is the difference between using thismessage:/ and resolving them directly against each other? The authors should also make it clear that the use of thismessage:/ does not mean that thismessage:/ should be added to relative URIs, by writing it, but that the use is implicit. From the description in RFC2557, of how to unpack received MHTML messages, it is clear that the sender can put a Content-Location header with an absolute URI in the message heading or in the heading of the text/html MIME part. RFC2557 gives an example of an MHTML message in which a relative URI in the HTML source has been transformed to an absolute Content-Location URI. A receiver of such a message would need to resolve the relative URI in the source to an absolute URI before being able to match that body part. Problem There is a problem with this example. If there is no absolute URI in the message heading or on the text/html part then the MIME part would not be matched using "thismessage:/". When this is the case the receiver is expected to retrieve the referenced object via HTTP. Which, of course, is not possible. This is a clear error in RFC2557. Apart from not being usable under all circumstances, the specification of the use of "thismessage:/" is not as clear as it should be. How to view the Content-Location header We have not been able to get answers concerning how to view the Content-Location header with regards to other e-mail header fields. Is Content-Location a structured or unstructured header field as defined in RFC822? And does this have implications for encoding and folding of URIs in Content-Location fields? Content-Location is a MIME field and as such should follow the syntax for fields according to [RFC2822]. When implementing our mailer, we chose to follow the specification of Content-Location in RFC2557, since we did not have the experience nor knowledge to decide whether Content-Location is structured or not nor if this has any consequences. Techniques more difficult than necessary Receiving MHTML messages The necessity that all relative URIs in a MHTML message using Content-Location, should be made absolute before matching HTML source and Content-Locations, is not a very good one. Besides the information about this being divided into two different chapters that do not seem well synchronized, we feel that this might be an unneccessary step that receivers of MHTML must take. It might have its cause in a desire to make the standard general. We have not seen any reasons for a mailer sending MHTML to ever need to make URIs in Content-Location headers any different from the URIs in the HTML source code. If this is true, then there would not be any reasons for not being able to match URIs directly against each other without making all relative URIs absolute. The reason for having receivers make all relative URIs absolute might be that two MIME parts should not be able to have the same URI. With web pages taken from the web this is never an issue. With other webpages there is always the possibility to use Content-ID instead. Acknowledgments Jacob Palme Fredrik Kilander Lars Enderin Sven Olofsson References Ref. Author, title [RFC2110]J. Palme, A. Hopmann: "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC2110, March 1997. [RFC2557]J. Palme, A. Hopmann: "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC2557, March 1999. [RFC2119]S. Bradner: "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, March 1997. [RFC2821]J. Klensin, Editor: "Simple Mail Transfer Protocol", RFC2821, April 2001. [HTTP] T. BernersLee, R. Fielding, H. Frystyk: "Hypertext Transfer Protocol HTTP/1.0. ", RFC 1945, May 1996. [RFC2119]S. Bradner: "Key words for use in RFCs to Indicate Requirements Levels. " RFC 2119, March 1997. [RFC2822]P. Resnick, Editor: "Internet Message Standard", RFC2822, April 2001.[RFC3160] S. Harris: "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", RFC3160, August 2001 [RFC2392] E. Levinson: "ContentID and MessageID Uniform Resource Locators", RFC2392, August 1998. [MIME1]N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996. .[MIME2]N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996. [MIME3]K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for NonASCII Text", RFC 2047, December 1996. [RFC2026] S. Bradner: "The Internet Standards Process", RFC2026, October 1996.[RFC2387] Edward Levinson: "The MIME Multipart/Related ContentType", RFC 2387, August 1998. [RFC2028]R. Hovey, S. Bradner: "The Organizations Involved in the IETF Standards Process", RFC2028, October 1996. [RFC3160]S. Harris: "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", RFC3160, August 2001. [RFC2396] T. BernersLee: "Uniform Resource Identifiers", RFC 2396, August 1998. [URLBODY] N. Freed and Keith Moore: "Definition of the URL MIME ExternalBody AccessType", RFC 2017, October 1996. [Hentze-Muto 2000]R. Hentze and A. Muto: Sending HTML in E-mail - Status Report 2000, May 2000, http://dsv.su.se/jpalme/ietf/mhtml.html#testprogs Author's Addresses Electrum 230 S164 40 Kista, Sweden Fax: +468783 08 29 Yvonne Backhans Phone: +4686672600 Emmylundsvgen 3:921 Email: yvonnebackhans@hotmail.com 171 72 Solna, Sweden Tina Hekkala Email: tinahek@yahoo.se Albacken Phone: +46855089893 152 93 Hl, Sweden Send questions and comments on this document also to: Jacob Palme Email: jpalme@dsv.su.se Skeppargatan 73 Phone: +46-8-16 16 67 115 30 Stockholm, Sweden or join the MHTML mailing list (http://dsv.su.se/jpalme/ietf/mhtml.html#mailing-list) and thereafter send comments to that list. This is an abbreviated translation of a thesis submitted to Stockholm University in partial fulfillment of the requirements for the degree of Master of Science in Computer and Systems Sciences. FILENAME \* MERGEFORMAT RFC-MHTMLTEST.doc TIME \@ "MMMM, yy" February, 04 BackhansHekkala Please do not implement based on this draft [Page ] Backhans-Hekkala Please do implement based on this draft [Page ] Body of the e-mail Heading of the e-mail MIME-encoded body Heading of a MIME part Content-Type: image/gif Content-Location: teckning.gif R0lGODlhewA5APcAAHJycnNzc3V1dXZ2dnd3d3h4eHl5eXp6ent7e3x8fH19fX5+fn9/f4CAgIGB gYKCgoODg4SEhIWFhYaGhoeHh4iIiImJiYqKiouLi4yMjI2NjY6Ojo+Pj5CQkJGRkZKSkpOTk5SU Content-Type: image/jpg Content-Location: http://www.dsv.su.se/~yvonne-b/yvonne.jpg R0lGODlhPABSAMQAAP///+He3tXU2sjK1bzB0K+3zKOtx5ajw4qavX2QuXCGtGR9r1dyrExppz9gojJWnSZMmBlClAAAAAAAAAAAAAAAA Content-Type: Text/html; charset="US-ASCII"