Draft issues for the MHTML meeting during the IETF meeting in San José, December 1996

0. Unresolved references to IETF drafts:

Internationalization of the Hypertext Markup Language". draft-ietf-html-i18n-05.txt. Not yet published as an RFC?

N. Freed & N. Borenstein: "Multipurpose Internet Mail Extensions (MIME) Part One: draft-ietf-822ext-mime-imb-07.txt Part Two: Media Types", draft-ietf-draft-ietf-822ext-mime-imt-02.txt. Published as RFC 2045 and RFC 2046.

N. Freed and Keith Moore: "Definition of the URL MIME External-Body Access-Type", draft-ietf-mailext-acc-url-01.txt, November 1995. Publidshed as RFC 2017.

1. URL-s which cannot be rewritten: The problem that in some cases it is not possible to know what is an URL and not an URL in HTML code containing applets, and that thus mhtml maybe will not work in such cases.

2. Interoperability tests: Has any interoperability tests between working implementations of the mhtml-spec been done yet?

3. Planning of interoperability tests: What should be tested? (see appendix A).

4. Will all or only a subset of the functions (see appendix A) be implemented by current implementations?

5a. Will rewriting of URLs be done before sending out HTML messages?

5b. Will rewriting of URLs be done after receipt of HTML messages?

5c. Which of the implementation methods described in chapter 4 of draft-ietf-mhtml-info-05.txt will be used?

  (a) Combing browser and e-mail in one integrated software package.
  (b) Rewriting the HTML at receipt and turning the result over to a web browser.
  (c) Using a translation table or other similar tool to turn information over from the mail program to the web browser.
  (d) Deliver the HTML pages from a proxy server which has the parts of message available.
  (e) The whole mail client built into a proxy server.

6. Use of multipart/alternative, inside or outside of multipart/related (chapter 8 of draft-ietf-mhtml-info-05.txt) & problems with the start parameter of multipart/related when referring to a multipart/alternative (see appendix B below).

7. Go through draft-ietf-mhtml-info-05.txt chapter by chapter and check which comments there are: Can also the info document be forwarded for publication as an informational document (not a standard)?

Appendix A: Table of important functionalities for HTML in e-mail:

Function

Implementation for generation

Implementation for receipt

Use of multipart/related

 

 


- for HTML with embedded graphics, etc.



- for sets of related HTML objects



Reference to embedded body parts



- using Content-ID-s



- using absolute Content-Location



- using relative URLs and no Content-Location



Use of combinations of multipart/related and multipart/alternative



Use of content-disposition header for recipients who do not handle mhtml



Use of HTML messages whose URLs for enbedded graphics must be resolved through HTTP retrieval from the source



Use of the message/external-body method for sending HTML in e-mail



Use of character sets in HTML messages



- US-ascii



- ISO 8859-1



- Other ISO 8859 variants



- ISO 10646/Unicode



- Other character sets



Appendix B: more about the multipart/alternative issue

(a) Inside the "Content&endash;Type Multipart/related", body parts can be specified with "Content&endash;Type: Text/plain" as the first choice, and "Content&endash;Type: Text/HTML" as the second choice:

Content&endash;Type: Multipart/related;
             type=MULTIPART/ALTERNATIVE 
   Content&endash;Type: MULTIPART/ALTERNATIVE
      Content&endash;Type: Text/plain
      ... plain text version of the document for recipients 
      whose mailers cannot handle Text/HTML ...
      Content&endash;Type: Text/HTML; charset=US&endash;ASCII 
         ... text of the HTML document ...
   Content&endash;Type: Image/GIF
   ... a body part, to which the HTML document has a link ...

(b) Outside the multipart/related:

Content-Type: Multipart/alternative
   Content-type: Text/plain
      ... plain text version of the document for recipients 
      whose mailers cannot handle Text/HTML ... 
   Content&endash;Type: Multipart/related; type=Text/HTML 
      Content&endash;Type: Text/HTML; charset=US&endash;ASCII 
         ... text of the HTML document ...
      Content&endash;Type: Image/GIF
         ... a body part, to which the HTML text has a link

When choosing between these two methods of employing multipart/alternative, note the following:

(1) Clients which do not support Multipart/related, and which thus will interpret it as Multipart/mixed, will with choice (a) display the inline objects. Thus, a recipient whose mailer can handle Image/gif but not multipart/related will still be shown the images, they will not be suppressed by being inside a suppressed branch of the Multipart/alternative.

(2) Choice (b) will not show inline images in the Multipart/Related, unless this information is repeated in both branches of the Multipart/Alternative.