At 14.44 -0800 97-11-03, Einar Stefferud wrote:
> I am asking Jacob to assemble a working version of our meeting agenda,
> so we can track our meeitng intentions as we approach the meeting, and
> so he can prepare the final agenda view graphs for the meeting just
> before we meet.
Since our standard is now finished, there is probably not need to
discuss items in the proposals. But issues we might want to discuss is:
1. Status of implementations
(in order to check if something has to be taken out of the standard
when going to draft standard, I can produce a form to fill in
to indicate what implementors are planning to support)
2. How should an implementation handle features it cannot handle?
Ignore them and say nothing, give error messages, turn the
document over to a web browser? My testing of a few early
implementations seem to indicate that implementors tend to
ignore and say nothing more than I like.
Example: HTML elements it cannot support,
methods of linking between body parts it cannot support,
inline parts which have to be looked up through http,
body parts of types it cannot support.
3. Use of the MHTML standard for information sent in other forms
than via SMTP. Can you for example use HTTP to download files
of the format
Content-Type: message/rfc822 (containing multipart/related) or
Content-Type: multipart/related or
Content-Type: multipart/<other subtypes>
and should web browsers support this?
4. Use of the MHTML standard for archiving of HTML documents.
Today web browsers usually have two variants of the Save
command, "Save as source" and "Save as text". Both only save
the HTML document, not the inline linked parts. Perhaps
browsers should support a third save alternative:
"Save as message" or "Save as MIME" which produces one
single file with all the inline linked parts in MHTML
format. This would be very useful, since it would allow
people to save the whole HTML page. If such a feature
is provided, should it save in the format message/rfc822
or in the format multipart/related? Multipart/related
has a problem, you have to save the parameters also.
If message/rfc822 is used, a simplified variant of RFC822
might be used not including all standard RFC822 headers.
For example, should "Save as message" produce Date and From
headers, or should this information be given in meta fields
in the HTML HEAD. So perhaps "Save as message" should only
produce an RFC822 heading with Content-Type and Content-
Transfer-Encoding and nothing more. Should we also, for
this application, recommend some particular Content-
Transfer-Encoding, for example recommmend that binary
body parts are not saved as 8BIT or BINARY?
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.
> We also need to decide when we are ready for WG last call on our new
> versions of our Proposed MHTML Standard so we can then ask for an IESG
> Last Call to be completed before we meet, if at all possible. If not
> possible to complete IESG before we meet, how should we proceed?
> My suggestion is that we quickly launch a one or two week WG last call
> on the docs that Jacob has prepared, and try to then shift into an
> IESG Last Call As Soon As Possible.
> Can I please have consensus on this plan?
Perhaps you should also include in this last call the two revised
documents from Ed Levinson:
Isaac Chan has sent me a list of small corrections to the latest
version of mhtml. Should I prepare a new version with his corrections
before issuing the last call?
Jacob Palme <[log in to unmask]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme