<br><br><div><span class="gmail_quote">On 4/16/07, <b class="gmail_sendername">Jon Barnett</b> <<a href="mailto:jonbarnett@gmail.com">jonbarnett@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
RFC 2557 was mentioned in the last thread.<br><a href="http://tools.ietf.org/html/rfc2557" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://tools.ietf.org/html/rfc2557</a> <br><br>After reading it in detail (and indeed writing a script to send HTML with inline images as attachments), I quite like it. It's simple and obvious enough and allows for a fallback to a real internet URL if a corresponding URL exists.
<br><br>The main gripe about it was that binary data is base64 encoded, which adds size to the file in the end.<br><br>A couple benefits to MHTML over ZIP are that HTTP headers are preserved and that the Content-Location header can directly associate a resource with it's Internet-hosted version, removing the need to change all the URLs (absolute or relative) in a document (and related documents, such as CSS files) to make it usable offline.
<br><br>zipping the final MHTML file could help with size.<br><br>Considering that there's already a standard, the trick is getting browsers to support it. <br><a href="http://en.wikipedia.org/wiki/MHTML" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://en.wikipedia.org/wiki/MHTML
</a><br><br>That pages tells a lot about what can save as MHTML but not enough about what can open and read MHTML.<br>
</blockquote></div><br><br clear="all"><br>-- <br>Jon Barnett