MHTML Working Group Alexander Hopmann INTERNET-DRAFT ResNova Software, Inc. <draft-hopmann-html-email-packaging-00.txt> Expires SIX MONTHS FROM---> February 20th, 1995 Packaging Aggregate HTML Objects Inside MIME Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Please send comments to the MHTML working group at <mhtml@segate.sunet.se>. To subscribe to this list, send a message to <listserv@segate.sunet.se> which contains the text "sub mhtml <your full name, not email address>". Discussions of the working group are archived at <URL:ftp://segate.sunet.se>. Abstract Although HTML was designed within the context of MIME, more than the specification of HTML as defined in RFC 1866 is needed for two electronic mail user agents to be able to interoperate using HTML as a document format. These issues include the naming of objects that are normally referred to by URIs, and the means of aggregating objects that go together. This draft describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these HTML objects. In addition it is hoped that these techniques will also apply to the wider category of URI-enabled objects. Table of Contents 1. Introduction 1.1 Purpose 1.2 Overall Operation 1.3 URI References 1.3.1 Use of Multipart/Related 1.3.2 Content-ID URL References 1.3.3 New MIME Content Headers 1.4 Other MIME Issues 2. Examples 3. Security Considerations 4. Acknowledgments 5. References 6. Author's Address 1. Introduction 1.1 Purpose Although HTML [1] is a valid MIME [2] type, RFC 1866 does not provide enough specification in order for two electronic mail user agents to be able to interoperate using HTML as a document format. This draft describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display HTML objects. In addition it is hoped that these techniques will also apply to the wider category of URI-enabled [3] objects. An HTML aggregate object is a MIME-encoded message that contains an HTML document as well as other data that is required in order to represent that object (inline pictures, style sheets, etc.). HTML aggregate objects can also include additional HTML documents that are linked to the first object, as well as other arbitrary MIME content. In designing HTML capabilities for electronic mail user agents (UAs), it is important to keep in mind the differing needs of several audiences. Mail sending agents will send aggregate HTML objects as an encoding of normal day-to-day electronic mail. Mail sending agents will also send aggregate HTML objects when a user wishes to mail a particular document from the World Wide Web to someone else. Finally mail sending agents will send aggregate HTML documents as automatic responders, providing access to WWW resources for non-IP connected clients. Mail receiving agents also have several differing needs. Some mail receiving agents will be able to receive an aggregate HTML document and display it just as any other text content type would be displayed. Others will have to pass this aggregate HTML document to an HTML browsing program, and provisions need to be made to make this possible. Finally several other constraints on the problem arise. It is important that it be possible for an HTML document to be signed and for it to be able to be transmitted to a client and displayed with a minimum chance of breaking the message integrity check that is part of the signature. 1.2 Overall Operation A mail user agent that wishes to send a content-type of HTML can just do so, so long as the normal data encoding issues are taken care of as specified in [2]. However at a basic level there are some differences between HTML being transferred by HTTP and HTML being transferred through Internet email. When transferred through HTTP, HTML by default uses the document character set ISO-8859-1. Within electronic mail, the default character set is US-ASCII. If a document uses any characters that are not in US-ASCII, the document must explicitly label the character set and perform appropriate MIME content encodings. Instead of applying normal MIME content encodings it is possible to translate non US-ASCII characters to HTML defined entity references. However it is inappropriate to use entity references to non-US-ASCII characters without labeling the document character set appropriately. 1.3 URI References The use of URI references creates some additional issues for aggregate HTML objects. Normal URI references can of course be used, however it is likely that many user agents may not be able to retrieve those objects referred to. This document provides a means for these additional objects to be transmitted with the HTML and for the links between these objects to be properly resolved. 1.3.1 Use of Multipart/Related Multiple objects should be aggregated using the multipart/related content type as defined in RFC 1872 [4]. RFC 1872 says that multipart/related should have parameters "start", and "type". The "start" parameter refers to the Content-ID of the sub-part which contains the main document, in this case, usually the primary HTML document. The main document should be the one first displayed by the receiving UA. The "type" parameter serves as a label for the type of the aggregate object, in this case "text/html". 1.3.2 Content-ID URL References An HTML body part can use Content-ID URLs as described by draft- levinson-cid-01.txt [5] to refer to other body parts of the same MIME message. Content-ID URLs can also refer to body parts in other MIME messages, but it is unlikely that many clients will be able to resolve the reference. 1.3.3 New MIME Content Headers In order to resolve URI references to other body parts, two new MIME content headers are required. Both of these place URIs in MIME header fields. Since MIME header fields have a limited length and URIs can get quite long, these lines may have to be folded. When the lines are folded, no additional non-white space characters may be introduced, and since white space is not allowed in URIs it is simply ignored. 1.3.3.1 Content-Base The Content-Base header field may be included in any MIME content header. It specifies the Content-Base for the body part and should be a full URL. Any relative URL references within the body part are made relative to the body parts "base URL". An HTML body part can also include a <BASE> tag. If it does contain a <BASE> tag, that <BASE> tag takes precedence over the Content-Base header field. 1.3.3.2 Content-Location The Content-Location content header may be included in any MIME subpart header. It specifies the URI that corresponds to the object present in that subpart. If a URL is specified using the Content-Location header, it should be a fully qualified URL. 1.4 Other MIME issues Several other tricky issues may exist regarding the deployment of HTML email, however they are out of the scope of this document. These issues include the use of multipart/alternative for content negotiation, the use of mail/WWW gateways, and the use of URLs referring to objects outside of the encapsulation (both to WWW-based objects, objects in other MIME documents, and objects in other parts of the same MIME message but not in the same multipart/related). The use of multipart/alternative is in no way an HTML-specific issue and no clear solution exists at this time for the problem of content negotiation though electronic mail. The use of mail/WWW gateways should be facilitated by the provisions of this document. However this document makes no attempt to specify the format of a request to such a gateway. The use of references to outside of the "encapsulating MIME object" is not something that can be prohibited, but it is simply something that the sending UA needs to realize creates a danger of the receiving UA not being able to resolve the reference. Finally, a sending user agent should not make any assumptions about the method that the receiving user agent will use to display the HTML files. For example it should not use Content- Disposition and/or "file:" URLs under the assumption that the receiving UA is going to save the pieces of the HTML aggregate object as files on a disk to be displayed by a separate browser. Content-Disposition should only be used as described in RFC 1806 in order to distinguish between file attachments and inline message components. 2. Examples The first example is the simplest form of an HTML email message. This is not an aggregate HTML object, but simply one by itself. This message contains a hot-link but does not provide the ability to resolve the hot-link. To resolve the hot-link the receiving client would need either IP access to the Internet, or an electronic mail web gateway. From: some.user@resnova.com To: someone.else@entropy.net Subject: Hello there Mime-Version: 1.0 Content-Type: text/html <html> <head></head> <body> <h1>Hi there!</h1> This is a rather pointless example of an HTML message.<p> Try clicking <a href=3D"http://www.resnova.com/">here.</a><p> </body></html> The second example shows a simple HTML document with a picture in it: From: some.user@resnova.com To: someone.else@entropy.net Subject: Hello there Mime-Version: 1.0 Content-Type: multipart/related; boundary=3Dabcdefghij start=3D"<12345@entropy.net>"; type=3D"text/html" --abcdefghij Content-Type: text/html Content-ID: <12345@entropy.net> <html> <head></head> <body> <h1>Hi there!</h1> This is a rather pointless example of an HTML message.<p> <img src=3D"cid:<45678@entropy.net>"><p> Try clicking <a href=3D"http://www.resnova.com/">here.</a><p> </body></html> --abcdefghij Content-Type: image/jpeg Content-ID: <45678@entropy.net> Content-Transfer-Encoding: Base64 jdisfdsufhsdjvbfdhvbfhbvfhbvfdvifdjrivjifdjvfivfd etc=85 --abcdefghij=97 The third example shows the use of Content-Location. This example could be a web page that was mailed to someone. Note that the starting body part still needs a Content-ID. From: some.user@resnova.com To: someone.else@entropy.net Subject: Hello there Mime-Version: 1.0 Content-Type: multipart/related; boundary=3Dabcdefghij start=3D"<12345@entropy.net>"; type=3D"text/html" --abcdefghij Content-Type: text/html Content-ID: <12345@entropy.net> Content-Location: http://www.entropy.net/mydoc.html <html> <head></head> <body> <h1>Hi there!</h1> This is a rather pointless example of an HTML message.<p> <img src=3D"http://www.entropy.net/myimg.jpg"><p> Try clicking <a href=3D"http://www.resnova.com/">here.</a><p> </body></html> --abcdefghij Content-Type: image/jpeg Content-Location: http://www.entropy.net/myimg.jpg Content-Transfer-Encoding: Base64 jdisfdsufhsdjvbfdhvbfhbvfhbvfdvifdjrivjifdjvfivfd etc=85 --abcdefghij=97 3. Security Some Security Considerations include the potential to mail someone an object, and claim that it is represented by a particular URI (by giving it a Content-Location: header field). There can be no assurance that a WWW request for that same URI would normally result in that same object. Because of this problem, receiving User Agents should not cache this data in the same way that data that was retrieved through an HTTP or FTP request might be cached. In addition, by allowing people to mail aggregate HTML objects, we are opening the door to other potential security problems that until now were only problems for WWW users. For example, some HTML documents now either themselves contain executable content (JavaScript) or contain links to executable content (The "INSERT" specification, Java). It would be exceedingly dangerous for a receiving User Agent to execute content received through a mail message without careful attention to restrictions on the capabilities of that executable content. 4. Acknowledgments Thanks to Dave Crocker, Roy Fielding, Ed Levinson, and Paul Hoffman who, with me, worked out most of the details of this draft in an informal discussion at the Dallas December 1995 IETF. Additional thanks to Greg Herlihy and Ed Levinson for reviewing this draft. Thanks also to Jacob Palme who encouraged the existence of the Mail HTML effort and addressed many of the issues in his drafts. 5 References [1] T. Berners-Lee and D. Connolly. "HyperText Markup Language Specification 2.0" RFC 1866, Proposed Standard <URL: http://ds.internic.net/rfc/rfc1866.txt>, November 1995. [2] N. Borenstein and N. Freed. "MIME (Multipurpose Internet Mail Extensions) Part One" RFC 1521, Proposed Standard <URL: http://ds.internic.net/rfc/rfc1521.txt>, September 1993. [3] T. Berners-Lee, L. Masinter, and M. McCahill "Uniform Resource Locators (URL)" RFC 1738, Proposed Standard <URL: http://ds.internic.net/rfc/rfc1738.txt>, December 1994. [4] E. Levinson "The MIME Multipart/Related Content-type" RFC 1872, Experimental <URL: http://ds.internic.net/rfc/rfc1872.txt>, December 1995. 6 Author's Address Alex Hopmann alex.hopmann@resnova.com President ResNova Software, Inc. 5011 Argosy Dr. #13 Huntington Beach, CA 92649
