LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives


MHTML Archives

MHTML Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave MHTML
Reply | Post New Message
Search Archives


Subject: Re: MHTML Agenda for IETF 40 in Washington & WG Last Call on our docs.
From: Jacob Palme <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Tue, 4 Nov 1997 20:26:12 +0100
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (90 lines)


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:

draft-ietf-mhtml-rel-v2-00.txt
draft-ietf-mhtml-related-02.txt

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

Back to: Top of Message | Previous Page | Main MHTML Page

Permalink



LISTSRV.NORDU.NET

CataList Email List Search Powered by the LISTSERV Email List Manager