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.