Date: Wed, 3 Dec 1997 23:59:45 +0100 To: mhtml@SEGATE.SUNET.SE From: Jacob Palme Subject: Re: MHTML Session Agenda Draft agenda for the MHTML meeting in Washington, December 1997 0.1 Select a taker of notes for the minutes. 0.2 Review the agenda and modify as needed. 1a Status of implementations. Are there any features in the standard which no one implements, and which thus might be cut off when publishing as an IETF draft. 1b The questionnaire on implementation status which I prepared and which can be found at: In HTML format: http://www.dsv.su.se/~jpalme/ietf/mhtml-impl-status-v1.html In RTF format: http://www.dsv.su.se/~jpalme/ietf/mhtml-impl-status-v1.rtf Should we ask implementors to fill it in? If so, when? 2 What should an implementor do with features they do not support. Is it permitted to just ignore things they do not support. Example: An implementation which cannot show graphics just ignores them, or an implementation which cannot handle a particular kind of link just ignores the objects referred to by this link. Any conformance requirements on this? 3. Allow multiple Content-Location statements in the same content heading? 4a Web browsers today typically have two save formats, save as text and save as source. Save as source saves only the HTML text, not the linked objects. The user can thus not use the saved HTML to display the message with inline objects again, unless the user has some means to retrieve these inline parts. Perhaps there should be a third option "save as message" which saves in message/rfc822 format, and thus really saves both the HTML text and the inline objects. 4b MHTML is not only a format for sending HTML in e-mail. It is also an archiving format, where a whole document with its inline linked objects can be saved in one file. Does this fact require some special action from us? 5 Caching issues: The consensus on the list seems to be that an MHTML message shows one instance of a web document at one time, and should not show a later version if a user retrieves it a few days later. (Except when Content-Type: message/external-body is used.) 6 Is there any need for discussion of interaction between MHTML and Content-Type: message/external-body. I do not know if this is a problem, we have never disucssed it. 7 I may have time to submit two small additional proposals to the informational document, one about readable HTML and one about combinations of multipart/alternative where one of the alternatives is an HTML form. If I have time to do this, we might wish to discuss it at the meeting. 8 Any other issues? 9 Time schedule for publication of new proposed standard and of progressing it to draft standard.