Editor's note: These minutes have not been edited. WG MHTML met as scheduled in the evening of 9 December 1996 in San Jose. The meeting agenda was followed, and is here used for the structure of these minutes. Attendees are listed in Appendix X. These minutes are prepared by Einar Stefferud, WG MHTML Chair, from notes provided by Jacob Palme, Dirk van Gulik, Ed Levinson, and Mark Joseph. All notes used here-in were also sent to the MHTML WG mailinglist . Respectfully submitted by Einar Stefferud, WG Chair . ISSUES ADDRESSED AT THE MHTML MEETING DURING THE IETF MEETING IN SAN JOSE, 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. Published as RFC 2017. Resolution: These will be resolved in due course for MHTML RFC publication. 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. Resolution: A clear warning needs to be in the INFO document, as this problem essentially cannot be solved. 2. Interoperability tests: Have any interoperability tests between working implementations of the mhtml-spec been done yet? Resolution: One action is to put example messages up at the WG MHTML web site. Another is to collect information on implementations and their problems and successes with interworking. 3. Planning of interoperability tests: What should be tested? (see appendix A). Resolution: Each implementor should their own stuff up on the net, and try to read others' stuff. Then discuss the problems on the list or privately, with final interworking results posted to the list. WE ned to be collecting evidence of interworking implementations for use in advancing the standard from Proposed to Draft status. 4. Will all or only a subset of the functions (see appendix A) be implemented by current implementations? Resolution: Working group chair will collect reports; and collate into which features are really in use. Area Director stated that more than one implementation will be needed. The required information must include how much of each part of the standard is implemented 5a. Will rewriting of URLs be done before sending out HTML messages? Resolution: Deferred to the info/implementation guide draft. 5b. Will rewriting of URLs be done after receipt of HTML messages? Resolution: Deferred to the info/implementation guide draft. 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. Resolution: Implementors stated that they are working on doing the following items listed above: (b+d+e) Jacob Palme (a+b) Pete Resnick (a+b) Chris Cotton (a+c) Mark Joseph (a) Alex Hopmann (a) Eric Berman (a) Linda Welsh, Lotus We expect others to join the party, but this provides a critical mass for the next stage. We noted that someone is working on each type of implementation listed in our agenda. Progress and problems will be reported and discussed on the WG mailing list: . 6. Use of multipart/alternative, inside or outside of multipart/related (chapter 8 of draft-ietf-mhtml-info-05.txt) and problems with the start parameter of multipart/related when referring to a multipart/alternative (see appendix B below). Cases a, and b, were considered. Resolution: Problem seems to be that multipart-related parameter does not really allow recursive use, ie. plain + html, where html is again multipart-related. Both examples (a & b) are valid MIME; but they mean quite different things. Is case a an issue? No. Nor is case b; In case a, type/location does not seem to be the problem. One can have more than one alternative. But the problem seems to be how far the pointing out can be. Conclusion? Cases a & b seem to be nice testing examples; makes the code complex, but that is the functionality that we wanted. 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 as a standard)? Resolution: Comments are solicited on the list; Jacob got very few comments back, and would like to see some more checks made. 8. Other items and issues. * WG MHTML should communicate with other WG Chairs to alert them to what MHTML is doing and delivering. * The WG asked for efforts to apply MHTML to PDF, in addition to applying it to HTML. This was directed to Steve Zilles * References to the INFO-draft that is in progress will be removed from the MHTML spec-drafts, as the INFO draft will not be published any time soon. 9. The meeting adjourned on schedule. 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-Type Multipart/related", body parts can be specified with "Content-Type: Text/plain" as the first choice, and "Content-Type: Text/HTML" as the second choice: Content-Type: Multipart/related; type=3DMULTIPART/ALTERNATIVE = Content-Type: MULTIPART/ALTERNATIVE Content-Type: Text/plain ... plain text version of the document for recipients whose mailers cannot handle Text/HTML ... Content-Type: Text/HTML; charset=3DUS&endash;ASCII ... text of the HTML document ... Content-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-Type: Multipart/related; type=3DText/HTML = Content-Type: Text/HTML; charset=3DUS&endash;ASCII ... text of the HTML document ... Content-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. APENDIX C: List of attendees at the session. 1. Einar Stefferud (WG Chair) 2. Jacob Palme 3. Edward Levinson 4. Mark Joseph 5. Hiroyuki Kajiura 6. Mark Fu 7. Juerg von Kaenel 8. Donal Hanna 9. Ron Daniel 10. Terry Allan 11. Harald Tveit Alvestrand 12. Mike Gahrns 13. David Johnson 14. Keith Lamond 15. Stephen Martin 16. Don Dumimu 17. L. A. Heberlon 18. Dan Sharon 19. William Flanigan 20. Larry Masinter 21. Carl Uno Manros 22. Sandro Mazzucato 23. Shin Okadu 24. Svante Nygnen 25. Alex Hopmann 26. Eric Berman 27. Chris Cotton 28. Steve Zilles 29: Pete Resnick NOTE: Any errors in names or addresses are due to transcription problems from the signup sheet. End of WG MHTML Minutes for 9 December, 1996...