Status of MHTML implementation in the spring of 2000

Fuller name

Test platform

Version

Short name

Microsoft Outlook Express

Windows NT

Windows NT

Qualcomm Eudora Pro

Macintosh (not fully tested)

Compaq Alpha Unix

Windows NT & Explorer 5

Explorer 5 from Windows NT

Explorer 5 from Windows NT

Explorer 5 from Windows NT

Facility

Can produce

Can receive

Multipart/related and Message-ID links to images

Without multipart/alternative

Multipart/alternative inside multipart/related

Multipart/alternative outside multipart/related

Multipart/related and Content-Location links

With absolute URLs

All except Hotm

Outl, Pine, Hotm, Juno

Relative URLs, base in Content-Location in a surrounding heading

Relative URLs, base in Content-Location in its own heading

Content-Location to be recursively applied to inner parts

Resolution through HTML <BASE> element

Multipart/alternative inside multipart/related

Multipart/alternative outside multipart/related

Unfolding of long URIs in MIME headers

1. Only one single of the tested implementations (Outlook Express) produces messages using Content-Location between body parts. This feature was added to the standard, in order to allow existing web pages to be sent through e-mail without modification of the HTML text. The reason why this is only supported by one implementations is that for some time, one major implementation (Netscape Messenger) did not support receipt of this format. Because of this, other implementations did not want to produce it, because their messages would then not be receivable with Netscape Messenger. However, Netscape Messenger now supports receipts of Content-Location. In fact almost all implementations now support receipt of this format. The reason for this is probably that since one major implementation (Outlook Express) sends in this format, all implementations want to support receipt of this format. Should we keep this in the standard, even though only one implementation produces this format? Should we encourage some more implementation to support this format? For example, a small not-general-purpose program just for mailing web pages and nothing else?
   
   
2. Half of the implementations do not support the variant of Content-Location containing relative URLs. The variant supported by almost all implementations for receipt is Content-Location containing absolute URLs. Should we change the standard to only include this variant?
   
   
3. Many major implementations support combination of multipart/related with multipart/alternative. This combination, however, is used in two different ways. Netscape Messenger sends messages with multipart/related inside multipart/alternative, all other implementations send with multipart/related outside multipart/alternative. For receipt, this combination is not well supported except with Content-ID relations between body parts, but done that way, several implementations can receive both variants. Rather strange was that Hotmail could receive only the test message with multipart/alternative outside, but could produce only messages with multipart/related outside! Should the standard say something about this combination? To get better interoperability, it might be specifically required that a conforming implementation must be able to receive both variants of the use of multipart/alternative?
   
   
4. The testers did not succeed in producing any messages with the rules for encoding of special characters and long rows using the tested mail clients. Should this facility be removed from the standard?